Software-defined multi-path virtual network

Abstract

Disclosed is a method of communication in a software-defined network (SDN) that includes a central controller, and a plurality of client nodes managed by the central controller, wherein each client node runs an SDN client. The method includes transmitting a connection request from first to second client node, wherein the connection request includes address candidate groups (ACGs) of network interfaces assigned to first client node, and wherein an ACG of a network interface includes a plurality of network addresses assigned to said network interface; transmitting a response including ACGs of network interfaces assigned to second client node, to first client node, forming a plurality of network interface pairs, forming a plurality of address candidate pairs for each network interface pair based on ACGs of first and second nodes, wherein an address candidate pair include an address of a network interface of client node, and an address of a network interface of second client node; attempting to establish a connection between first and second client nodes over each address candidate pair; and initiating data exchange between first and second client nodes over connections established therein.

Description

[0001] Title

[0002] Software-defined Multi-Path virtual network

[0003] Field

[0004] The present invention relates to network connectivity, and more specifically multipath P2P connectivity among the devices.

[0005] Background

[0006] In computer networks, Local Area Network (LAN) refers to a physical network between devices in a relatively small geographical area such as an office building. They are connected together using a mixture of cables, switches, routers and wireless links such as Wi-Fi.

[0007] Wide Area Networks (WAN) refers to a network between devices across a large geographical area such as cities, countries or even continents. An example of this is the internet. Devices across a WAN are connected via leased communication links such as DSL, 4G / 5G, Fiber, MPLS, or Satellite links. Typical enterprise networks consist of multiple LANs in different office branches or sites connected together as a WAN.

[0008] When devices outside the enterprise network (e.g. an employee working remotely) need to connect to one of the LANs securely, it has to utilize Virtual Private Network (VPN) software that creates a secure, encrypted tunnel from the device over the internet and into the enterprise LAN.

[0009] While connectivity within a LAN is typically low-latency and high capacity, the same cannot be said for WAN or VPN connectivity as they have to traverse the internet. Indeed, businesses historically elected to lease an MPLS line from their carrier for their site-to-site WAN connectivity, which is a dedicated highly-reliable network but that is typically much more expensive compared to other WAN links. MPLS however cannot address the issue of VPN connectivity, since devices in remote locations are not guaranteed to have access to one end of an MPLS line.

[0010] A fairly recent innovation in the space of enterprise connectivity is SD-WAN, which is a technology that enables enterprise branches to be connected over multiple WAN links simultaneously where the distribution of traffic across the WAN links is controlled via the central SD-WAN controller that attempts to enhance the reliability and efficiency of the inter-branch connectivity. The combination of multiple cheap WAN links has proven a good replacement for MPLS links for most businesses.

[0011] SD-WAN, however, is unable to fully address the issue of reliable remote connectivity since it is often deployed either as a hardware solution, making it expensive and inconvenient, or as virtual machine software, making it technically challenging to deploy on end devices that may not support virtual machine frameworks due to performance or compatibility reasons.

[0012] Additionally, in cases where multiple remote SD-WAN devices need to communicate with each other, such as drones and drone operators, both ends of the communication require public IP addresses or they need to rely on other SD- WAN devices that have public IPs in a hub-and-spoke architecture, increasing the communication latency and creating a performance bottleneck.

[0013] Summary

[0014] According to the invention there is provided, as set out in the appended claims, a method of communication in a software-defined network (SDN) that includes a central controller, and a plurality of client nodes managed by the central controller, wherein each client node runs an SDN client. The method includes transmitting a connection request from a first client node to a second client node, wherein the connection request includes one or more address candidate groups (ACGs) of one or more network interfaces assigned to the first client node, and wherein an ACG of a network interface includes a plurality of network addresses assigned to said network interface; transmitting a response from the second client node to the first client node upon receiving the connection request, wherein the response includes one or more ACGs of one or more network interfaces assigned to the second client node; forming a plurality of network interface pairs, wherein a network interface pair includes a network interface of the first client node, and a network interface of the second client node; forming a plurality of address candidate pairs for each network interface pair based on the ACGs of the first and second nodes, wherein an address candidate pair include an address of a network interface of the first client node, and an address of a network interface of the second client node; attempting to establish a connection between the first and second client nodes over each address candidate pair; and initiating data exchange between the first and second client nodes over one or more connections established therein.

[0015] In an embodiment of the present invention, the first and second nodes establish a P2P connection between the first and second nodes over each address candidate pair.

[0016] In an embodiment of the present invention, the ACG of a network interface includes local, public and relay addresses of the network interface.

[0017] In an embodiment of the present invention, the method further includes marking an address candidate pair as successful address candidate pair, if a connection is established between the first and second client nodes over said address candidate pair; selecting a successful address candidate pair for each network interface or network path pair, by favouring connections using local addresses, followed by public addresses, and finally relayed addresses; and exchanging data between the first and second client nodes over each selected candidate pair.

[0018] In an embodiment of the present invention, the method further includes transmitting the connection request from the first client node to the second client node through one of the following: the central controller, or another client node to which both client nodes have an existing P2P connection to, or over an existing P2P connection over a different network interface pair, or through a rendezvous server, and transmitting the response from the second client node to the first client node through same channel.

[0019] In an embodiment of the present invention, the forming the virtual network comprises creating a plurality of tokens, and associating a plurality of network configurations with corresponding plurality of tokens; distributing the plurality of tokens to corresponding plurality of client nodes; authenticating a client node to the central controller using corresponding token; and providing corresponding network configuration to the client node when corresponding authentication is successful, wherein once authenticated, each client node receives periodic updates from the central controller including changes to corresponding network configuration, online status of other client nodes, and current connectivity status of the virtual network.

[0020] In an embodiment of the present invention, each network configuration includes virtual topology of the virtual network, information on other client nodes in the virtual network including corresponding virtual IP address, routing entries, default gateways, multi-path scheduling and traffic shaping rules including QoS policy, application-aware routing, rate-limiting and prioritization, and traffic filtering rules.

[0021] In an embodiment of the present invention, the method further includes performing a plurality of functions by each SDN client, wherein the plurality of functions include authorization, traffic shaping, encryption and decryption, traffic filtering, congestion control, multipath P2P NAT traversal, transparent TCP proxy, multipath scheduling, multipath signalling and routing.

[0022] In an embodiment of the present invention, the method further includes creating one or more UDP network sockets at each client node, wherein each UDP network socket binds to a network interface; and establishing multiple P2P connections between a pair of client nodes through respective plurality of UDP network sockets. In an embodiment of the present invention, the method further includes using NAT traversal through UDP hole punching to establish connectivity between respective pair of UDP sockets when the pair of client nodes are not able to connect directly, wherein the UDP hole punching includes using an existing P2P connection between the client nodes to exchange the information needed to establish a new P2P connection over a different network interface pair.

[0023] In an embodiment of the present invention, the UDP hole punching technique includes using a third node to which the pair of client nodes in the new connection have an existing P2P connection.

[0024] In an embodiment of the present invention, the SDN client is deployed as a VPN client.

[0025] In another aspect of the present invention, there is provided a software-defined network (SDN). The SDN includes a central controller; and a plurality of client nodes managed by the central controller. Each client node runs an SDN client, and wherein an SDN client at a first node, is configured to transmit a connection request to a second client node, wherein the connection request includes one or more address candidate groups (ACGs) of one or more network interfaces assigned to the first client node, and wherein an ACG of a network interface includes a plurality of network addresses assigned to said network interface; receive a response from the second client node based on the connection request, wherein the response includes one or more ACGs of one or more network interfaces assigned to the second client node; form a plurality of network interface pairs, wherein a network interface pair includes a network interface of the first client node, and a network interface of the second client node; form a plurality of address candidate pairs for each network interface pair based on the ACGs of the first and second nodes, wherein an address candidate pair include an address of a network interface of the first client node, and an address of a network interface of the second client node; attempt to establish a connection between the first and second client nodes over each address candidate pair; and initiate data exchange between the first and second client nodes over one or more connections established therein.

[0026] There is also provided a computer program comprising program instructions for causing a computer program to carry out the above method which may be embodied on a recording medium, carrier signal or read-only memory.

[0027] Various embodiments of the present invention enable the deployment of both SD- WAN and VPN functionalities through a single user-space software process, making it deployable on all mainstream devices without additional hardware or modifications to the operating system. It creates a single virtual network for both WAN and remote access, greatly reducing complexity, and enabling more reliable remote connectivity. Further embodiments provide a method for connecting devices securely and reliably with minimum latency across different physical networks, thereby making it a significantly more performant, cost-effective and lower complexity alternative to VPNs or SD-WANs.

[0028] The multipath P2P connectivity method connects any number of devices securely in a virtual network using one or more P2P connections that go over different network paths allowing these devices to benefit from the network bandwidth and diversity available across the different paths without needing complex infrastructure and maintaining minimum latency. On top of this it enables central management and monitoring of this virtual network. This invention is applicable to any use case where there’s a need for secure, reliable and low-latency connectivity, especially over public networks. Some examples include connectivity for Beyond Visual Line of Sight (BVLOS) Unmanned Aerial and Ground Vehicles, connected medical devices, connectivity for transportation vehicles, private 5G replacement through multiple WiFi links for Industry 4.0. Further, compared to traditional SD-WAN, the invention provides a more cost effective and more deployable solution to enabling secure and reliable connectivity, as well as centralized network management. Furthermore, compared to traditional VPNs, the invention provides significantly more reliable connectivity. Brief of the

[0029] The invention will be more clearly understood from the following description of an embodiment thereof, given by way of example only, with reference to the accompanying drawings, in which:

[0030] FIG.1A illustrates an environment, wherein various embodiments of the present invention can be practiced;

[0031] FIG.1 B illustrates communication between an admin, the central controller and a client device, in accordance with an embodiment of the present invention;

[0032] FIG.2 illustrates an SDN client running on a first client device, in accordance with an embodiment of the present invention;

[0033] FIG.3 illustrates a full mesh of multi-path P2P connectivity among the two devices;

[0034] FIG.4 illustrates connection establishment flow among the central controller and the two nodes, such as node A and node B, in accordance with an embodiment of the present invention;

[0035] FIG.5 illustrates multiple performance evaluations conducted, in accordance with an embodiment of the present invention;

[0036] FIG. 6 shows latency results for the same test. It shows a 92% reduction in delay spikes above 100ms and 26% reduction in average delay when using the invention vs a single link; and

[0037] FIG.7 illustrates measured packet latency using multi-connectivity with upto 4 WiFi links simultaneously using a replication scheduler.

[0038] FIG.1A illustrates an environment 100, wherein various embodiments of the present invention can be practiced.

[0039] The environment 100 includes a plurality of client devices, of which first, and second and third client devices 102a, 102b and 102c are shown, and a central controller 104 communicatively coupled to the plurality of client devices, through a communication network 106.

[0040] Each client device is a part of the software-defined network (SDN) 102, and runs a SDN client that performs the functions of a traditional SD-WAN device as well as a VPN client. The central controller 104 is hosted in an accessible server, and is configured to manage and monitor the SDN 102.

[0041] FIG.1 B illustrates communication between an admin 108, the central controller 104 and a client device 102a, in accordance with an embodiment of the present invention. The admin 108 refers to an administrator that creates the virtual network using the central controller 104. The admin 108 creates the virtual network, creates the secret token, create a configuration and associate it with token. The admin 108 then installs token on the client device. Thus, the admin 108 creates the SDN 102 and provisions secret access tokens which are then distributed to the plurality of client devices that are part of the SDN 102. In another embodiment of the present invention, the topology of the SDN 102 is determined by the central controller 104. For example, it can be a full mesh topology, a star topology (a.k.a hub and spoke) or a hybrid. This means that some nodes in the SDN 102 may be connected directly or indirectly via other nodes.

[0042] The central controller 104 is further configured to associate a specific configuration to each token. In an embodiment of the present invention, the configuration for each token includes the Virtual topology, Virtual IP address and local routing table entries, information on other nodes in the network including virtual IP address, their routing entries, default gateway (yes / no), multi-path scheduling and traffic shaping rules including QoS policy, application-aware routing, rate-limiting and prioritization, and traffic filtering rules.

[0043] Further, the client device 102a is configured to authenticate to the central controller 104 using the secret token and, if successful, it will retrieve its assigned configuration. Once authenticated, the client device 102a may receive periodic updates from the central controller 104 containing changes to the configuration, online status of other nodes, and current connectivity status of the SDN 102.

[0044] FIG.2 illustrates an SDN client 202a running on a first client device 204a, in accordance with an embodiment of the present invention. The SDN client 202a is in communication with the central controller 206 (similar to the central controller 104). It can be seen that the central controller 206 is in communication with Devices A and B, wherein both the devices A and B authenticate to the central controller through respective secret tokens. Although, the SDN client 202a of only the Device A is shown, it will be apparent to one of ordinary skill in the art, that Device B includes similar SDN client.

[0045] The SDN client 202a is configured to perform various functions including authorization, traffic shaping, encryption and decryption of, traffic filtering, congestion control, multipath P2P NAT traversal, transparent TCP proxy, multipath scheduling, multipath signalling and routing.

[0046] The SDN client 202a encrypts certain application streams by relying on symmetric encryption using DTLS with keys generated from using its secret tokens, which are 256-bit strings or more. The encryption can be selectively enabled / disabled for specific application flows based on the configuration.

[0047] The SDN client 202a is further configured to perform traffic shaping which includes enforcing rate limits and priorities over the available network paths, in addition to applying different multi-path scheduling approaches.

[0048] The SDN client 202a may act as a transparent TCP proxy. The data from application streams that is transmitted over multiple underlying physical links can experience high jitter in the arrival time of the packets. This can be particularly problematic for TCP flows, as they rely on Return-trip Time Out (RTO) timers to drive re-transmissions and congestion control and may result in degraded performance. To address this issue, the SDN client 202a may be configured to behave as a transparent TCP proxy to prevent the stacking of congestion control and reliability layers and avoid TCP meltdown. When it does that, it may take over reliability and congestion control using its custom algorithms.

[0049] The SDN client 202 may perform multipath scheduling, in which depending on the configuration provided by the central controller, respective node may replicate, split, load balance or switch the various application data streams across the available network paths. It may apply different schedulers on a per-application basis, and it may identify applications using an IP 5-Tuple.

[0050] The SDN client 202a is further configured to append custom protocol headers that include sequence numbers, application identifiers and other relevant information.

[0051] The SDN client 202a is further configured to incorporate Multi-path P2P connectivity using NAT traversal technique. The multipath P2P connectivity uses a UDP-based multi-path transmission protocol which includes capacity estimation, congestion control, reliability, packet sequencing and multi-path scheduling (similar to MP-QUIC). In the multipath P2P connectivity, the SDN client is configured to establish bonded communication tunnels over multiple Peer-to-Peer (P2P) or relayed connections to other nodes in the virtual network.

[0052] To enable multi-path communication, similar to SD-WAN, without changes to the device, the SDN client 104 creates multiple user-space UDP network sockets 208a and 208b and binds them to different physical network interfaces 210a and 210b through system calls. Examples of physical interfaces include WiFi interface or Ethernet interface. The SDN client 202a then establishes multiple P2P connections over these UDP sockets 208a and 208b to the UDP sockets of other nodes in the network.

[0053] FIG.3 illustrates a full mesh of multi-path P2P connectivity among the two devices 302a and 302b. The devices 302a and 302b are similar to the devices A and B of FIG.2. Upon authenticating and retrieving the virtual topology, the SDN client of the device 302a may attempt to create one or more Peer-to-Peer (P2P) connections to other online nodes that it is directly connected to in the virtual topology (i.e. multi-path P2P connectivity). To facilitate the P2P connectivity, the SDN client of the device 302a utilizes a NAT traversal technique known as ‘UDP hole punching’. This is necessary because remote devices are not guaranteed to have a static public IP, unlike more static traditional SD-WAN devices.

[0054] The UDP hole punching is a specific way of doing NAT traversal in order to establish P2P connectivity. If two nodes are behind NAT layers, they do not have a public IP and may not be able to talk directly and require a public relay. The UDP hole punching allows them to establish direct (i.e. P2P) connectivity in this situation. Having the P2P connectivity eliminates the cost, complexity and added latency associated with a public relay. The standard way of implementing UDP hole punching relies on a public rendezvous server that may help the devices exchange the initial information required to establish the P2P connectivity.

[0055] In an embodiment of the present invention, two novel ways of doing UDP hole punching is introduced that eliminate the need for the public rendezvous server. One method includes using an existing P2P connection between the nodes to exchange the information needed to establish a new P2P connection over a different network path (e.g. different network interface pair). Another method includes using a third node to which both devices in the new connection have an existing P2P connection to.

[0056] FIG.4 illustrates connection establishment flow among the central controller and the two nodes, such as node A and node B, in accordance with an embodiment of the present invention. In the context of the present invention, the devices are interchangeably referred to as nodes.

[0057] For NAT traversal, a rendezvous server is needed to enable address exchange between nodes and facilitate P2P connectivity. Depending on network load, the choice of the rendezvous server can be one of the following: the central controller, another node in the network to which both peers of the new connection have an existing P2P connection to, or an existing P2P connection between the two peers over a different network path. In some cases, if both devices are behind symmetric NAT, direct P2P connectivity may not be possible, and they need to rely on a relay server to communicate.

[0058] At onset, node A receives periodic updates from the controller including information that node B is online. Thereafter, node A gathers address candidates and configured network interfaces. The configured network interfaces include the specific set of network interfaces that corresponding admin may have assigned for the node A to use as part of its multi-connectivity. For example, the admin may configure node A to use network interfaces called WiFi 1 , WiFi 2 and LTE 1 in its multi-connectivity. The client software (for example, the SDN client) may create one UDP socket that is bound to each configured network interface. The hole punching allows this UDP socket to create a P2P connection to another UDP socket on another node, such as node B in the network.

[0059] An address candidate group refers to various type of address candidates collected for a specific network interface. Example of type of address candidates include local address, public address or relayed address for a network interface. A local address is the address that a network interface has been assigned locally either by having it set as a static IP or receiving it from a DHCP server. The public address is the address that is assigned to the network interface by the Internet Service Provider (ISP) when it attempts to access the internet. This address may be assigned by a Network Address Translation (NAT) unit in the ISP core network. The relay addresses is an address allocated to a network interface from a relay server using a relay protocol, such as TURN. Relay addresses are used as a last resort when P2P connectivity is not possible due to a restrictive NAT in the ISP network.

[0060] For each address candidate group, a relay is used when P2P connectivity is not possible or if the configuration from the central controller forces it. The choice of relay can be one of the following depending on load, the central controller, a public relay, or another node to which both peers have an existing P2P connection to. Then, the node A transmits a connection request containing an address candidate group (ACG) of each network interface to node B, through one of the following: the central controller, or another node to which both nodes have an existing P2P connection to, or through a randevouz server.

[0061] When node B receives the connection request, it will collect its own address candidates groups for respective network interface or network path, and transmit them back via the same channel. Therefore, each node forms a plurality of address candidate pairs for each network interface pair based on the ACGs of the first and second nodes, wherein an address candidate pair includes an address of a network interface of node A, and an address of a network interface of node B. Thereafter, attempts are being made to establish connectivity over all address candidate pairs. If connectivity is successful to one or more address candidates in any of the groups, the data exchange may begin between the nodes A and B, and if not, the process may be retired after a pre-configured timeout. Typically, an address candidate pair include an address of network interface or network path of node A, and an address of network interface or network path of node B. If connectivity is successful to multiple address candidates in the same group (i.e. multiple connections created for the same address candidate group), then those address candidate pairs are marked as successful address candidate pairs. Further, only one successful candidate pair is selected for each network interface pair, favouring connections using local addresses, followed by public addresses, and finally relayed addresses.

[0062] If only some of the address candidates' groups had successful pairs, the data exchange may begin but the above process may be retried only for the failed groups.

[0063] In an example, node A may have candidates [a_l, a_P, a_R, b_l, b_P, b_R] representing the local, public and relay addresses respectively of network interfaces a and b on node A, and node B may have candidates [c_l, c_P, c_R] representing the local, public and relay addresses of network interface c on node B. Herein, there are two network interface pairs are (a, b) and (a, c). The goal is to end up with selecting a successful candidate pair for each network interface pair, i.e. successful candidate pairs [a_x, c_x] and [b_x, c_x], where the priority for selecting x is I > P > R. Then, data may be exchanged between nodes A and B over each selected pair.

[0064] It is to be noted that in traditional NAT traversal, peers exchange address candidates of all the network interfaces on the device need to find a viable connectivity candidate. If multiple address candidates are viable, then they are filtered to the highest priority candidate, which is typically the ones utilizing local addresses. However, in the context of multi-path P2P communication, we wish to end up with one viable candidate for each address candidate group belonging to a specific network interface or network path from each side, and only filter multiple address candidates within the same group pair.

[0065] In some cases, there are network paths to the destination node with a different bottleneck available over other nodes in the virtual network. As such, the configuration from the central controller may request a forced relay for a specific connection (e.g. Satellite-Ethernet in the above example) or may request both a direct P2P and a forced-relay versions of the same connection. A forced relay is when a node is forced to use another node or public server to relay the traffic from a network interface or network path instead of establishing a P2P connection.

[0066] To accomplish this, the nodes may tag address candidate groups belonging to different network interfaces with a unique Identifier and only multiple successful P2P connections within the same address candidate will be filtered based on traditional priorities. This refers to the process of address candidate exchange in the context of multi-connectivity. Basically, in traditional P2P connectivity, the nodes would simply get all their private address candidates, all their public address candidates and all their relay candidates, and send them to each other. If the nodes had more than one network interface, the candidates would include all the network interfaces. Then they would try to create a P2P connection using the other node’s private candidates. If not successful, they would try the public candidates. If not success, they would try the relay candidates. The goal of traditional P2P connectivity is to create a single P2P connection over any pair of network interfaces between the two nodes, following the priorities explained previously.

[0067] However, in accordance with an embodiment of the present invention, multiple P2P connections are created between pairs of network interfaces. For example, if each node has a WiFi and a cellular interface, four P2P connections may be created as follows:

[0068] 1. WiFi_node1 <-> WiFi_node2

[0069] 2. WiFi_node1 <-> Cellular_node2

[0070] 3. Cellular_node1 <-> WiFi_node2

[0071] 4. Cellular_node1 <-> Cellular_node2

[0072] Each P2P connection prioritize address candidates in the same manner as a traditional P2P connection. Therefore, each node tags the address candidates when exchanging them to let the other node know which ones belong to which network interface.

[0073] It is to be noted, that the communication takes place simultaneously between a pair of nodes on multiple connections / links. The establishing multiple P2P connections does not inherently create congestion. It depends on how the data is scheduled across them and whether they share a bottleneck.

[0074] A simple example is where one node has a fiber connection that’s like 1 Gbyte / sec and the other node has 2 cellular connections each with 100 Mbyte / sec. The nodes would then establish 2 P2P connections: fiber <-> cellular_1 & fiber <-> cellular_2.lf the cellular connections do not share a bottleneck, then the connectivity between these 2 nodes will be able to obtain a speed of 200 Mbyte / sec, which is double what it would be if the nodes only used one connection.

[0075] In the example mentioned with 2 nodes having 2 interfaces each, and creating 4 connections, it is likely that some of these connections share a bottleneck. However, by establishing these connections, the scheduler on each node can discover which connections have the least propagation delay. For example, the WiFi node 1 <-> WiFi node 2, and the Cellular node 1 <-> Cellular node 2 can have the best delay out of the 4 connections. The scheduler can detect the shared bottlenecks, using an algorithm, and schedule data over the lowest propagation delay paths.

[0076] FIG.5 illustrates multiple performance evaluations conducted, in accordance with an embodiment of the present invention. The test has been conducted in a vehicle moving at an average speed of 25 km / h and evaluated the loss rate of video traffic when transmitting over 1 5G link (traditional VPN) and 2 5G links using the method of the present invention. The results 5 show a 99.1 % reduction in average loss when using the invention vs a single link. This is consistent with the theory that a loss only happens when both links fail simultaneously. Fig 5 shows the performance difference between using a single 5G link and 2 5G links for transmitting video traffic from a moving vehicle. It shows significant reduction in loss when using two links, re-affirming that the losses were not correlated and why using two links is useful.

[0077] FIG. 6 shows latency results for the same test. It shows a 92% reduction in delay spikes above 100ms and 26% reduction in average delay when using the invention vs a single link.

[0078] FIG.7 illustrates measured packet latency using multi-connectivity with up to 4 WiFi links simultaneously using a replication scheduler. The measurement results below show that by combining multiple WiFi transmissions, a latency in the order of 1 ms at 99.999% reliability can be achieved, which is in the order of 10x faster than what a private 5G network provides based on measurements from a Private 5G network. As a result, this is an attractive alternative for smaller scale Industry 4.0 applications which achieves higher performance at a significantly reduced costs for both equipment and management, and without need for private frequency spectrum. In the specification the terms "comprise, comprises, comprised and comprising" or any variation thereof and the terms include, includes, included and including" or any variation thereof are considered to be totally interchangeable, and they should all be afforded the widest possible interpretation and vice versa.

[0079] The invention is not limited to the embodiments hereinbefore described but may be varied in both construction and detail.

Claims

Claims1. A method of communication in a software-defined network (SDN) that includes a central controller, and a plurality of client nodes managed by the central controller, wherein each client node runs an SDN client, the method comprising: transmitting a connection request from a first client node to a second client node, wherein the connection request includes one or more address candidate groups (ACGs) of one or more network interfaces assigned to the first client node, and wherein an ACG of a network interface includes a plurality of network addresses assigned to said network interface; transmitting a response from the second client node to the first client node upon receiving the connection request, wherein the response includes one or more ACGs of one or more network interfaces assigned to the second client node; forming a plurality of network interface pairs, wherein a network interface pair includes a network interface of the first client node, and a network interface of the second client node; forming a plurality of address candidate pairs for each network interface pair based on the ACGs of the first and second nodes, wherein an address candidate pair include an address of a network interface of the first client node, and an address of a network interface of the second client node; attempting to establish a connection between the first and second client nodes over each address candidate pair; and initiating data exchange between the first and second client nodes over one or more connections established therein.

2. The method as claimed in claim 1 , wherein the first and second nodes establish a P2P connection between the first and second nodes over each address candidate pair.

3. The method as claimed in claim 1 , wherein the ACG of a network interface includes local, public and relay addresses of the network interface.

4. The method as claimed in claim 2 further comprising: marking an address candidate pair as successful address candidate pair, if a connection is established between the first and second client nodes over said address candidate pair; selecting a successful address candidate pair for each network interface or network path pair, by favouring connections using local addresses, followed by public addresses, and finally relayed addresses; and exchanging data between the first and second client nodes over each selected candidate pair.

5. The method as claimed in any preceding claim further comprising transmitting the connection request from the first client node to the second client node through one of the following: the central controller, or another client node to which both client nodes have an existing P2P connection to, or over an existing P2P connection over a different network interface pair, or through a rendezvous server, and transmitting the response from the second client node to the first client node through same channel.

6. The method as claimed in any preceding claim, wherein the forming the virtual network comprises: creating a plurality of tokens, and associating a plurality of network configurations with corresponding plurality of tokens; distributing the plurality of tokens to corresponding plurality of client nodes; authenticating a client node to the central controller using corresponding token; and providing corresponding network configuration to the client node when corresponding authentication is successful, wherein once authenticated, each client node receives periodic updates from the central controller including changes to corresponding network configuration, online status of other client nodes, and current connectivity status of the virtual network.

7. The method as claimed in any preceding claim, wherein each network configuration includes virtual topology of the virtual network, information on otherclient nodes in the virtual network including corresponding virtual IP address, routing entries, default gateways, multi-path scheduling and traffic shaping rules including QoS policy, application-aware routing, rate-limiting and prioritization, and traffic filtering rules.

8. The method as claimed in any preceding claim further comprising performing a plurality of functions by each SDN client, wherein the plurality of functions include authorization, traffic shaping, encryption and decryption, traffic filtering, congestion control, multipath P2P NAT traversal, transparent TCP proxy, multipath scheduling, multipath signalling and routing.

9. The method as claimed in any preceding claim further comprising: creating one or more UDP network sockets at each client node, wherein each UDP network socket binds to a network interface; and establishing multiple P2P connections between a pair of client nodes through respective one or more UDP network sockets.

10. The method as claimed in any preceding claim further comprising: using NAT traversal through UDP hole punching to establish connectivity between respective pair of UDP sockets when the pair of client nodes are not able to connect directly, wherein the UDP hole punching includes using an existing P2P connection between the client nodes to exchange the information needed to establish a new P2P connection over a different network interface pair.

11. The method as claimed in any preceding claim, wherein the UDP hole punching technique includes using a third node to which the pair of client nodes in the new connection have an existing P2P connection.

12. The method as claimed in any preceding claim, wherein the SDN client is deployed as a VPN client.21 a central controller; and a plurality of client nodes managed by the central controller, wherein each client node runs an SDN client, and wherein an SDN client at a first node, is configured to: transmit a connection request to a second client node, wherein the connection request includes one or more address candidate groups (ACGs) of one or more network interfaces assigned to the first client node, and wherein an ACG of a network interface includes a plurality of network addresses assigned to said network interface; receive a response from the second client node based on the connection request, wherein the response includes one or more ACGs of one or more network interfaces assigned to the second client node; form a plurality of network interface pairs, wherein a network interface pair includes a network interface of the first client node, and a network interface of the second client node; form a plurality of address candidate pairs for each network interface pair based on the ACGs of the first and second nodes, wherein an address candidate pair include an address of a network interface of the first client node, and an address of a network interface of the second client node; attempt to establish a connection between the first and second client nodes over each address candidate pair; and initiate data exchange between the first and second client nodes over one or more connections established therein.

Images