Layer four optimization for a virtual network defined over public cloud

Patent metadata

Field	Value
Publication number	US-11089111-B2
Application number	US-201916252696-A
Country	US
Kind code	B2
Filing date	Jan 20, 2019
Priority date	Oct 2, 2017
Publication date	Aug 10, 2021
Grant date	Aug 10, 2021

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.

First claim

We claim:

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 ,

Assignees

• Vmware Inc

Inventors

• Markuze Alex
• Dar Chen
• Bergman Aran
• Cidon Israel
• Venugopal Prashanth
• Zohar Eyal

Classifications

• H04L43/20

  the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV · CPC title

• H04L43/08

  Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters · CPC title

• H04L41/0895

  Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements · CPC title

• H04L41/40

  using virtualisation of network functions or resources, e.g. SDN or NFV entities · CPC title

• H04L67/56

  Provisioning of proxy services (store-and-forward switching systems in data switching networks H04L12/54) · CPC title