IP Library Granted Patent US 11,089,111
Granted Patent B2
US 11,089,111 · App. 16/252,696 · Granted Aug 10, 2021

Layer four optimization for a virtual network defined over public cloud

Inventors: Alex Markuze (Ramat Gan, IL); Chen Dar (Magshimim, IL); Aran Bergman (Givatayim, IL); Israel Cidon (San Francisco, CA); Prashanth Venugopal (San Francisco, CA); Eyal Zohar (Shimshit, IL)
Assignee: VMWARE, INC.
H04L67/141H04L12/465H04L12/4625H04L12/4633H04L12/4641H04L63/00H04L63/0272H04L67/10H04L67/28H04L69/162H04L69/163H04L69/30H04L69/326
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 11,089,111
App. No.
16/252,696
Granted
Aug 10, 2021
Kind
B2
Abstract

Some embodiments establish for an entity a virtual network over several public clouds of several public cloud providers and/or in several regions. In some embodiments, the virtual network is an overlay network that spans across several public clouds to interconnect one or more private networks (e.g., networks within branches, divisions, departments of the entity or their associated datacenters), mobile users, and SaaS (Software as a Service) provider machines, and other web applications of the entity. The virtual network in some embodiments can be configured to optimize the routing of the entity's data messages to their destinations for best end-to-end performance, reliability and security, while trying to minimize the routing of this traffic through the Internet. Also, the virtual network in some embodiments can be configured to optimize the layer 4 processing of the data message flows passing through the network.

Claims (53)

1. A method of performing a layer four connection split operation on a computer that is on a path traversed from a source machine to a destination machine, the computer comprising a multi-core processor, the method comprising:

at the computer,

receiving a new connection request sent from the source machine and destined for the destination machine;

identifying, for the new connection request, a particular processor core of the computer to match a source-side socket and a destination-side socket of the computer that are defined for the computer to have a source-side connection with the source machine and a destination-side connection with the destination machine;

storing, in a local storage of the particular core, a destination-side search tuple that identifies the defined destination-side socket;

after establishing the source-side connection with the source machine and defining the source-side socket, using the particular core to search the local storage to find the destination-side search tuple identifying the destination-side socket that matches the source-side socket; and

using the matched source-side and destination-side sockets to relay messages between the source and destination machines.

2. The method of claim 1 , wherein

the connection request is part of a message comprising a set of attributes, and

identifying the particular core comprises computing a value from the set of attributes and using the value to identify the particular core.

3. The method of claim 2 , wherein

the set of attributes comprise message header values include source and destination network addresses,

computing the value comprises computing a hash value, and

using the value comprises using the hash value as an index that identifies a record in a lookup table that provides an identifier associated with the particular core.

4. The method of claim 1 further comprising:

assigning a destination-side handler to the particular core of the processor;

wherein storing the destination-side tuple comprises using the destination-side handler to store the destination-side search tuple in the local storage of the particular core.

5. The method of claim 4 , wherein the local storage is a local cache of the particular core.

6. The method of claim 1 , wherein

the destination-side search tuple stores (i) a socket identifier that identifies the destination-side socket and (ii) a key identifier that contains a set of attributes associated with the connection request, and

using the particular core to search the local storage comprises:

after establishing the source-side connection with the source-side connection socket,

using the key identifier to identify the destination-side search tuple stored in the local storage, and

retrieving the socket identifier from the identified destination-side search tuple to identify the destination-side socket that matches the source-side connection socket.

7. The method of claim 1 , wherein the connection is a TCP connection, and the connection request is a SYN packet of a three-way TCP handshake.

8. The method of claim 7 further comprising forwarding the SYN request to a next hop along the path as part of the destination-side connection, wherein the source-side connection is established once the three-way TCP handshake is completed with a prior hop along the path from the source machine to the destination machine.

9. The method of claim 1 , wherein the source-side and destination-side connections are created for a machine executing on the computer, the machine being a virtual machine or container.

10. The method of claim 9 , wherein the computer is in a public cloud and the machine operates as a cloud relay that performs a layer four connection split for a connection that is being requested between the source and destination machines through one or more public clouds.

11. A non-transitory machine readable medium storing a program for performing a layer four connection split operation on a computer that is on a path traversed from a source machine to a destination machine, the computer comprising a multi-core processor for executing the program, the program comprising sets of instructions for:

receiving a new connection request sent from the source machine and destined for the destination machine;

identifying, for the new connection request, a particular processor core of the computer to match a source-side socket and a destination-side socket of the computer that are defined for the computer to have a source-side connection with the source machine and a destination-side connection with the destination machine;

storing, in a local storage of the particular core, a destination-side search tuple that identifies the defined destination-side socket;

after establishing the source-side connection with the source machine and defining the source-side socket, using the particular core to search the local storage to find the destination-side search tuple identifying the destination-side socket that matches the source-side socket; and

using the matched source-side and destination-side sockets to relay messages between the source and destination machines.

12. The non-transitory machine readable medium of claim 11 , wherein

the connection request is part of a message comprising a set of attributes, and

the set of instructions for identifying the particular core comprises a set of instructions for computing a value from the set of attributes and using the value to identify the particular core.

13. The non-transitory machine readable medium of claim 12 , wherein

the set of attributes comprise message header values include source and destination network addresses,

the set of instructions for computing the value comprises a set of instructions for computing a hash value, and

the set of instructions for using the value comprises a set of instructions for using the hash value as an index that identifies a record in a lookup table that provides an identifier associated with the particular core.

14. The non-transitory machine readable medium of claim 11 , wherein the program further comprises a set of instructions for assigning a destination-side handler to the particular core of the processor, wherein the set of instructions for storing the destination-side tuple comprises a set of instructions for using the destination-side handler to store the destination-side search tuple in the local storage of the particular core.

15. The non-transitory machine readable medium of claim 14 , wherein the local storage is a local cache of the particular core.

16. The non-transitory machine readable medium of claim 11 , wherein

the destination-side search tuple stores (i) a socket identifier that identifies the destination-side socket and (ii) a key identifier that contains a set of attributes associated with the connection request, and

the set of instructions for using the particular core to search the local storage comprises sets of instructions for:

after establishing the source-side connection with the source-side connection socket,

using the key identifier to identify the destination-side search tuple stored in the local storage, and

retrieving the socket identifier from the identified destination-side search tuple to identify the destination-side socket that matches the source-side connection socket.

17. The non-transitory machine readable medium of claim 11 , wherein the connection is a TCP connection, and the connection request is a SYN packet of a three-way TCP handshake.

18. The non-transitory machine readable medium of claim 17 , wherein the program further comprises a set of instructions for forwarding the SYN request to a next hop along the path as part of the destination-side connection, wherein the source-side connection is established once the three-way TCP handshake is completed with a prior hop along the path from the source machine to the destination machine.

19. The non-transitory machine readable medium of claim 11 , wherein the source-side and destination-side connections are created for a machine executing on the computer, the machine being a virtual machine or container.

20. The non-transitory machine readable medium of claim 19 , wherein the computer is in a public cloud and the machine operates as a cloud relay that performs a layer four connection split for a connection that is being requested between the source and destination machines through one or more public clouds.

Assignments (3)
CHANGE OF NAME Recorded Apr 15, 2024
From: VMWARE, INC.
To: VMWARE LLC
Reel/Frame 067102/0314 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 12, 2019
From: NICIRA, INC.
To: VMWARE, INC.
Reel/Frame 049743/0073 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Mar 28, 2019
From: MARKUZE, ALEX; DAR, CHEN; BERGMAN, ARAN; CIDON, ISRAEL; VENUGOPAL, PRASHANTH; ZOHAR, EYAL
To: NICIRA, INC.
Reel/Frame 048732/0880 →
Continuity (4)
Continuation In Part 16192774 · Nov 15, 2018
Continuation In Part 15972083 · May 4, 2018
Provisional Application 62566524 · Oct 2, 2017
Related Publication 20190158605A1 · May 23, 2019
Cited By (37)
US 12,206,575 US 12,218,800 US 12,218,845 US 12,236,229 US 12,237,990 US 12,250,114 US 12,261,777 US 12,267,364 US 12,316,524 US 12,335,131 US 12,355,655 US 12,368,676 US 12,375,403 US 12,401,544 US 12,425,332 US 12,425,335 US 12,425,347 US 12,425,395 US 12,483,968 US 12,489,672 US 12,506,678 US 12,507,120 US 12,507,148 US 12,507,153 US 12,513,023 US 12,526,183 US 12,549,465 US 12,563,438 US 12,568,039 US 12,587,468 US 12,603,827 US 12,603,848 US 12,632,330 US 12,652,217 US 12,659,719 US 12,671,646 US 12,719,782