HK1247001B - System and method for a global virtual network - Google Patents

Description

Systems and methods for global virtual networks

This application claims priority to U.S. Provisional Patent Application No. 62/108,987, filed January 28, 2015, U.S. Provisional Patent Application No. 62/144,293, filed April 7, 2015, U.S. Provisional Patent Application No. 62/151,174, filed April 22, 2015, U.S. Provisional Patent Application No. 62/174,394, filed June 11, 2015, International Patent Application No. PCT/US2015/064242, filed December 7, 2015, U.S. Provisional Patent Application No. 62/266,060, filed December 11, 2015, and International Patent Application No. PCT/US2016/012178, filed January 5, 2016, all of which are incorporated herein by reference. U.S. Provisional Patent Application No. 62/089,113, filed December 8, 2014, and U.S. Provisional Patent Application No. 62/100,406, filed January 6, 2015, are incorporated herein by reference.

Technical Field

The present disclosure relates generally to networks and, more particularly, to the configuration and operation of a global virtual network (GVN).

Background Art

While "last mile connectivity" has improved dramatically in recent years, long-distance connectivity and throughput issues still exist due to distance, protocol limitations, peering, interference-related issues, and other problems and threats. GVN provides secure network optimization services to clients on top of their standard Internet connections.

This application provides an overview of GVN components and describes related technologies that can be used as GVN elements. GVN elements can operate independently or in a GVN ecosystem, such as using the GVN architecture for their own purposes, or can be deployed to enhance the performance and efficiency of the GVN.

This overview also describes how other technologies can benefit from GVN, either as standalone deployments that use some or all of GVN's components, or can be quickly deployed as standalone mechanisms on top of an existing GVN to leverage its benefits.

Humans can perceive latency of 200 milliseconds or higher, as this is typically the average human reaction time to an event. If latency is too high, online systems such as thin clients connecting to cloud-based servers, customer relationship management (CRM), enterprise resource planning (ERP), and other systems will perform poorly and may even cease to function due to timeouts. High latency combined with high packet loss can render the connection unusable. Even if data gets through, at certain times, excessive slowness can result in a poor user experience (UX), and in these cases, users may ultimately refuse to accept the situation, effectively viewing the poorly delivered service as useless.

To address some of these issues, various technologies have been developed. One technology is WAN optimization, which typically involves a hardware (HW) device at the edge of a local area network (LAN) that establishes a tunnel to another WAN optimization HW device at the edge of another LAN, thereby forming a wide area network (WAN) between the two hardware devices. This technology assumes that the two devices are connected to each other via a stable connection. WAN optimizers strive to compress and protect data streams, which generally results in speed gains. The business drive to adopt WAN optimization is to save data capacity sent, thereby reducing data transmission costs. The disadvantage of this technology is that it is typically point-to-point and can be difficult when the connection between the two devices is poor, because there is little or no control over the traffic path through the Internet between the two. To address this issue, users of WAN optimizers often choose to run their WANs on MPLS or DDN lines or other dedicated circuits, incurring additional costs and often entailing rigid, fixed point-to-point connections.

In the market at the time of writing this patent, some vendors focus on selling hardware, without focusing on providing connectivity services over the Internet between their hardware devices. Other vendors are service providers, and they may provide simple endpoint devices or software that customers can install on their own devices to connect to the service provider's cloud servers as a link to the provider's packaged services, but the primary focus of these vendors is service provision.

Direct links such as MPLS, DDN, dedicated circuits, or other types of fixed point-to-point connections provide guaranteed quality of connection and quality of service (QoS). These links are expensive and typically take a long time to install due to the need for physical cabling from each point of presence (POP) on each side of the connection. A point-to-point topology works well when connecting from one LAN to resources in another LAN via this directly connected WAN. However, when a gateway (GW) to the general internet is located at one end of the LAN, such as at corporate headquarters, traffic from a remote LAN in a subsidiary country can be routed to the internet via the GW. Traffic slows down as it returns over the internet to a server in the same country as the subsidiary. Traffic must then flow from the LAN across the WAN to the LAN where the GW is located, then across the internet back to the server in the original country, then back across the internet to the GW, and finally back along the dedicated line to the client device within the LAN. This effectively doubles or even triples (or even worse) the global transit time to access this nearby site, which should only require a fraction of the global latency. To overcome this problem, alternative connectivity via another internet line with appropriate configuration changes and additional equipment can provide local traffic to the internet at each end of the system.

Another option for establishing a WAN link from one LAN to another involves building a tunnel, such as an IPSec or other protocol tunnel, between two routers, firewalls, or equivalent edge devices. These are typically encrypted and can provide compression and other logic to improve connectivity. There is little or no control over the routing between the two points, as they rely on the policies of various intermediary participants on the Internet, who route their own traffic through their networks and have peer relationships with other carriers and/or network operators. Firewalls and routers, switches, and other devices from several equipment vendors often have tunneling options built into their firmware.

Software-based virtual private networks (VPNs) provide privacy via a tunnel between the client device and the VPN server. These offer encryption advantages and, in some cases, compression advantages. However, there is also little or no control over how traffic flows between the VPN client and the VPN server, and between the VPN server and the host server, host client, or other devices at the destination. These are typically point-to-point connections, requiring each device using the VPN to install client software and requiring a certain level of technical expertise to maintain each device's connection. If the VPN server exit point is in close proximity to the destination host server or host client via a high-quality communication path, performance will be good. If it is not, performance will be significantly limited and usability will be unsatisfactory. VPN users often need to disconnect from one VPN server and reconnect to another to access content from one region in a high-quality or local manner, relative to content from another region.

The Global Virtual Network (GVN) is a type of computer network built on top of the Internet. It provides global, secure network optimization services using a globally distributed network of devices securely linked by advanced tunnels. These devices collaborate and communicate via application programming interfaces (APIs), database replication, and other methods. Traffic within the GVN is always routed along the optimal communication path managed by Advanced Smart Routing (ASR), driven by an automated system that combines builders, managers, testers, algorithmic analysis, and other methods to adapt to changing conditions and learn over time in order to configure and reconfigure the system.

GVN provides services on top of one or more regular Internet connections to provide secure, reliable, fast, stable, accurate, and centralized parallel connectivity. These benefits are achieved by compressing the data stream, which is transmitted through multiple wrapped, disguised, and encrypted tunnels between the EPD and the access point server (SRV_AP) in close proximity to the EPD. The connection quality between the EPD and the SRV_AP is continuously monitored.

A GVN is a combination of a hardware (HW) endpoint device (EPD) with installed software (SW), a database (DB), and other automation modules of the GVN system such as the Neutral Application Programming Interface Mechanism (NAPIM), a reverse channel manager, a tunnel manager, and more features that connect the EPD to distributed infrastructure devices such as the Access Point Server (SRV_AP) and the Central Server (SRV_CNTRL) within the GVN.

Algorithms continuously analyze the current network state, taking into account subsequent trends plus long-term historical performance, to determine the best traffic route to take and the best SRV_AP or SRV_AP series to push traffic to. Configuration, communication paths, and other changes are made automatically and on the fly, requiring minimal or no user interaction or intervention.

Advanced intelligent routing in EPD and SRV_AP ensures that traffic flows from its origin to its destination via the most optimal path through the simplest possible GVN "Layer 3." Client devices connected to the GVN view this Layer 3 as a normal Internet path, but with fewer hops, greater security, and, in most cases, lower latency than traffic flowing to the same destination via the regular Internet. Logic and automation operate at the GVN's "Layer 2," where the GVN's software automatically monitors and controls the underlying routing and construction of virtual interfaces (VIFs), multiple tunnels, and the bonding of communication paths. The GVN's Layers 3 and 2 exist above the GVN's operational "Layer 1," which interacts with the underlying Internet devices.

Summary of the Invention

The present invention discloses a system and method for connecting devices via a virtual global network. The network system may include a first device communicating with a first endpoint device. The network system may include a second device communicating with a second endpoint device. The first device and the second device may be connected to a communication path. The communication path may include one or more intermediate tunnels connecting each endpoint device to one or more intermediate access point servers and one or more control servers.

According to other aspects of this embodiment, at least one of the first endpoint device and the intermediate access point server is configured to perform a Domain Name System (DNS) query to locate the second device.

According to other aspects of this embodiment, at least one of the first endpoint device and the intermediate access point server is configured to perform a Domain Name System (DNS) query from a cache memory to locate the second device.

According to other aspects of this embodiment, at least one of the intermediate access point servers is configured to cache content.

According to other aspects of this embodiment, at least one of the endpoint device and the intermediate access point server is configured to perform intelligent routing based on the global virtual network.

According to other aspects of this embodiment, the intelligent routing is based on at least one of best bandwidth, lowest delay time, least hops, and no packet loss.

According to other aspects of this embodiment, the intelligent routing is based on at least one of real-time statistics and historical statistics.

According to other aspects of this embodiment, at least one of the endpoint device and the intermediate access point server is configured to perform firewall services.

According to other aspects of this embodiment, the firewall service is between the first device and the intermediate access point server.

According to other aspects of this embodiment, the firewall service is between the first device and an intermediate access point server and the second endpoint server.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to facilitate a more complete understanding of the present invention, reference is now made to the accompanying drawings, in which similar elements are marked with similar numerals or reference symbols. These drawings should not be interpreted as limiting the present invention, but are intended to be used for illustrative purposes only.

FIG1 illustrates a block diagram of techniques used and implemented by a global virtual network ("GVN").

Figure 2 shows a high-level block diagram of the Internet.

3 is a block diagram illustrating the resolution of a Uniform Resource Locator (URL) to a numeric Internet Protocol (IP) via the Domain Name System (DNS).

4 is a simplified diagram illustrating the upstream and downstream paths taken by data from a host client device (C##) to another host client or host server device (S##).

5 is a simplified diagram illustrating boundary switches in the path taken by data from a host client device (C##) to another host client or host server device (S##).

FIG6 illustrates some example threats and issues that exist on the Internet.

FIG. 7 illustrates content delivery network (CDN) resolution and delivery of region-specific content.

FIG8 illustrates the operation of the proxy server.

FIG9 shows a point-to-point tunnel established between two gateway devices.

FIG10 shows the relationship of security features between device scope, system-wide scope, communication scope, and device cooperation.

FIG11 shows the information flow between devices in a global virtual network.

Figure 12 depicts the stack used to support automation of some devices in the GVN.

FIG13 shows a GVN topology including a backbone segment on the Internet or dark fiber.

FIG14 shows a distributed firewall (FW) in a cloud implemented by a GVN.

Figure 15 shows a multi-perimeter firewall (MPFW) in the cloud driven by a global virtual network.

FIG16 shows a logical view of the software architecture of three types of network devices working together as part of a global virtual network (GVN).

FIG. 17 illustrates a GVN using a hub and spoke topology with backbone segments and octagonal routing.

FIG18 shows the backbone connections between some GVN global nodes and their corresponding service areas in North America, Europe, and Asia.

FIG19 illustrates the connectivity between various devices within the GVN.

Figure 20 shows how the GVN modules and devices interact.

FIG21 shows additional details about how the GVN modules and devices interact.

Figure 22 shows how the GVN modules and devices interact with other devices on the Internet.

FIG23 illustrates multiple tunnel connectivity between an endpoint device (EPD) and an access point server (SRV_AP).

Figure 24 is a simplified example diagram of how the Internet works today, taking into account hop counts or time to live (TTL) and the paths taken due to peering relationships and associated routing policies.

Figure 25 shows the strategic positioning of infrastructure to enhance performance.

Figure 26 shows how GVN incorporates technologies such as Network Slingshot.

FIG27 shows how the tables in the databases of the various GVN devices relate to each other.

Figure 28 shows the collaborative efforts among various modules, mechanisms, technologies and other components of GVN.

Figure 29 shows the Advanced Smart Routing (ASR) feature of GVN.

Figure 30 shows a series of encrypted tunnels established between a client (C) and a server (S).

Figure 31 shows the information flow required for both peers in a peer pair.

32 to 35 illustrate the third layer of the GVN with respect to the neutrality and security of the GVN tunnel.

FIG36 shows weaving multiple network structures together into a network tapestry framework.

FIG37 shows the communication paths for automatic device collaboration in GVN.

Figure 38 illustrates the issues and challenges of dynamic tunnel establishment.

FIG. 39 illustrates bridging two LANs into a wide area network (WAN) via two or more EPDs.

Figure 40 shows a Multi-Perimeter Firewall Mechanism (MPFWM) running on a GVN.

Figure 41 shows a GVN stack built on top of the Internet (OTT).

Figure 42 compares the Internet Protocol IP stack, the OSI model, and the GVN network stack.

Figure 43 shows the global Internet flows between countries via numerous possible routes.

Figure 44 compares the Internet Protocol IP stack, the OSI model, and the GVN network stack.

Figure 45 shows a tunnel between two LANs via a GVN.

Figure 46 shows GNV layer 1, layer 2 and layer 3 operations.

Figure 47 shows the Advanced Smart Routing (ASR) feature and elements of the geographic destination mechanism of the GVN within the endpoint device (EPD).

FIG. 48 shows an example of multiple parallel traffic paths taken via a GVN.

Figure 49 depicts automatic Advanced Smart Routing (ASR) from one device to a second device.

Figure 50 shows the security perimeter between the BB/backbone layer below the perimeter and the IP/Internet layer above the perimeter.

Figure 51 is a flow chart of Advanced Smart Routing (ASR) within a Global Virtual Network (GVN).

Figure 52 is a flow diagram of the various routes available from an origin to a destination through the GVN.

53 is a flow chart of an algorithm that controls the routing of traffic from an origin device to an endpoint device.

Figure 54 shows the modules required for automatic device collaboration and information exchange in GVN.

FIG55 shows the communication between EPD, SRV_CNTRL and SRV_AP via the Neutral API Mechanism (NAPIM) of GVN.

FIG56 illustrates various types of communications available between GVN devices via NAPIM.

Figure 57 depicts the API call groups between different types of devices within a global virtual network (GVN).

Figure 58 describes the steps taken by an API call initiated from a client device, sent to a server device, and returned to the client.

Figure 59 is a flow chart showing the interaction between the EPD and SRV_AP to obtain geographic destination functionality.

Figure 60 depicts device collaboration within a geographic destination.

Figure 61 shows how a globally distributed parallel file system (PFS) operates within a GVN.

DETAILED DESCRIPTION

Overview

FIG2 is a block diagram illustrating the technologies used and implemented by a global virtual network ("GVN"), including the GVN core component G0, GVN modules G100, and the technologies G200 implemented by the global virtual network GVN. The GVN core includes a mechanism overview G1 and its components, namely the topology G2 layer, the fabric G3 layer, the logic G4 layer, and the control G5 layer. The GVN core G0 also includes information about and relationships between GVN elements G6.

The GVN may include plug-ins and/or independent GVN modules G100, including but not limited to: the Neutral API Mechanism ("NAPIM") module G102 described in PCT/US16/12178; the Geographic Destination ("Geo-D") module G104 described in PCT/US15/64242; the Advanced Intelligent Routing ("ASR") module G106, the Connection Module G108 and other modules G110 described in U.S. Provisional Patent Application US62/151,174.

GVN also provides a platform for implementing other technologies, including but not limited to: Network Tapestry G202; MPFWM G204; Network Slingshot G206; Network Beacons G208; Granularity of a Tick G210; and Other Technologies G212. These are described in U.S. Provisional Patent Application Nos. 62/174,394 and 62/266,060.

The GVN module (G100) and the technology implemented by the GVN (G200) may operate on top of an existing GVN as an integral part of the GVN, or may be independent and employ all or some separate parts of the GVN to support its own independent operation.

Figure 2 shows a high-level block diagram of the Internet. The average user has a very rough understanding of how the Internet works. A host source 2100 is the starting point and represents a client device, which can be a computer, mobile phone, tablet, laptop, or other such client. This client connects to a host server 2300 via the Internet 2200 to send or retrieve content, or to another host client 2303 to send or receive information.

Users with less technical knowledge might assume that traffic follows path 2P002 to the host server, not even realizing that their data will transit through the Internet. Alternatively, they might assume that traffic flows directly to another client device via path 2P006.

Users with more knowledge of how the Internet works will understand that traffic flows to the Internet 2200 via path 2P004 and then flows to the host server target 2300 via path 2P102 or to the host (client) target 2302 via path 2P104.

A more technically savvy user will further understand that when an email is sent, it leaves their client device 2100, travels via path 2P004 to the Internet 2200, and then travels via path 2P202 to the email server 2202. The recipient of the email will then request retrieval of the email via their host client 2302, along path 2P104 to the Internet, and then along path 2P204 to the mail server 2202.

This is roughly how much the average person knows about the Internet.

3 is a block diagram illustrating the resolution of a Uniform Resource Locator (URL) to a numeric Internet Protocol (IP) via the Domain Name System (DNS).

Content is requested 3000 from a host client (C) 3100 to a host server (S) 3300 as a file or data stream or data chunks or is pushed from the host client (C) 3100 to the host server (S) 3300. A response or content delivery 3002 is returned from the host S to the host C as a file or data stream or data chunks. A host client device 3100 in a client-server (CS) relationship with a host server (S) requests access to content from a remote host server (S) or sends data to a remote host server (S) via a uniform resource locator (URL) or other network-reachable address.

The initial connection from the host client (C) 3100 to the Internet 3206 is shown as 3P02, that is, the connection from the host client (C) to the point of presence (POP) 3102 that can be directly faced. In other cases, the host client (C) may be located in a local area network (LAN), which is then connected to the Internet via a point of presence (POP) and can be called the last mile connection. The point of presence (POP) 3102 represents the connection from the endpoint to the Internet provided by the service provider (ISP) via their network and interconnection. This can be, but is not limited to, cable, fiber, DSL, Ethernet, satellite, dial-up and other connections. If the URL is a domain name rather than a numeric address, then this URL is sent to a domain name system (DNS) server 3104, where the domain name is converted to an IPv4 or IPv6 or other address for routing purposes.

Traffic from host client (C) 3100 to host server (S) 3300 is routed over the Internet 3206, which represents transmission between POPs (3102 and 3302), including peering, backhaul, or other transmission at network boundaries.

The connection 3P04 between the POP 3102 and the Domain Name System 3104, which is used to look up a numeric address from a Uniform Resource Locator (URL) to obtain an IPv4 address or other numeric address of a target server (S), can be accessed directly from the POP or via the Internet 3206. The connection 3P06 from the ISP's POP 3102 to the Internet 3206 can be a single-hosted or multi-hosted connection. Similarly, the connection 3P08 from the Internet 3206 to the remote ISP can also be a single-hosted or multi-hosted connection. This connection is typically to the Internet-facing POP 3302 of the ISP or Internet Data Center (IDC). The connection 3P10 from the remote ISP's POP 3302 to the host server (S) can be direct or via multiple hops.

Lookups from URLs or hostnames to numeric addresses via the Domain Name System are currently standard on the Internet, and the system assumes that the DNS servers are integrated and that DNS server results are current and trustworthy.

Figure 4 is a simplified diagram illustrating the upstream and downstream paths taken by data from a host client device (C##) to another host client or host server device (S##). The numbers used in device labels, such as C01 or S08, are for identification purposes to locate the individual devices, and the numbers themselves do not imply or suggest that one device is larger or has more power than another.

Figure 4 shows a host client device (C##), a host server device (S##), a switch (SW##), a router (R##), a regional router (RR##), an edge router (ER##), and a core router (CR##). A communication path or pipe (P##) refers to the connection between two devices, and the thickness of the line is used to represent the size of the pipe or its bandwidth capacity. The thinner the line, the lower the megabits per second (Mbps). The thicker the line, the higher the Mbps or gigabits per second (Gbp). P## distances are not drawn to scale, and hop counts or time to live (TTL) and latency or round-trip time (RTT) are not considered when referring to P## between devices.

A simplified local area network (LAN) is downstream of switch (SW) SW01. It consists of wired connections P01 and P04 to client devices C01 and C04. Wireless connections are represented by dashed lines P02 and P03 between wireless hub WLAN01 and wireless client devices C02 and C03.

The connection P05 between the LAN and its internet service provider's (ISP) point of presence (POP) R01 can also be called the "last mile." This POP R01 is the hub that connects the other spokes P06, P07, P08, and P09 to corresponding switches at other clients, such as SW02, SW03, SW04, and SW05. There is also an upstream path P16 to the regional router (RR) RR02.

This hub and spoke topology is illustrated for POPs R02, R03, and R04, their spoke connections (e.g., P10, P11, P12, P13, P14, P15, P51, P52, P53, P54, P55, P56, P57, P58, P86) to their respective switches (e.g., SW06, SW07, SW08, SW09, SW10, SW11, SW12, SW13, SW14, SW15, SW16, SW17, SW18, SW19, SW20), and their connections (e.g., P17, P18, P46, P28) to their regional routers (e.g., RR02, RR03, RR04, RR05).

A further upstream connection P19 from regional router RR02 to edge router ER02 describes the connection to an edge router of the ISP network. Edge router ER02 has a link P20 to core router CR03. This can be considered the backbone of the Internet. Link P32 between CR01 and CR02 can describe a very large backbone, known as a backhaul network or, when connecting multiple national networks, an international backhaul network.

POPs R01 and R02 are both connected to regional router RR02 and this may indicate, but is not limited to, that these two POPs are within the same ISP's network.

For connectivity between devices within Router R01's network and devices within Router R04's network, traffic will take one of many possible paths, such as P16->P19->P20->P30->P31->P24->P27->P28. This may describe connectivity peering between two or more different ISPs' networks, with potential for other carrier peering points in between, depending on the owner of the infrastructure through which the traffic is transmitted. Traffic passing through the backbone will be carried by the pipe with the highest potential capacity. Traffic between Router R01 and Router R04 can also be carried via the path P16->P41->P44->P23->P27->P28. While this path may appear shorter, due to pipe size, intermediate devices, peering relationships, and policies of the intermediate ISPs, this second path may be the least efficient for controlling edge router ER03 to route traffic between the two other ISPs. There may also be bottlenecks between them.

Another feature shown is the connectivity of host servers S08 to S12 connected to switch SW13. This could be in an Internet data center (IDC) or in a local area network (LAN). Switch SW13 is also connected to router R03 via P53 and to regional router RR04 via P46. Connection P46 could represent a leased line or direct digital connection for enhanced connectivity.

Another feature shown in this figure is that P32 is located at the most upstream path reachable, and the independent host device is located at the most downstream path reachable. Downstream of the core processors CR04, CR06, and CR07 is the edge router ER## connected to the regional router RR##, which is connected down to the router R## located in the POP.

There may be other possibilities not described herein and in fact, each router R## has multiple spokes leading to switches SW## and there are many more pipes P## between devices. There may also be more layers of equivalent regional routers RR## or edge routers ER## devices or other devices in the sequence.

FIG5 is a simplified diagram illustrating edge switches in the path taken by data from a host client device (C##) to another host client or host server device (S##). This is very similar to FIG4, with one exception. On the backbone between core routers CR01 and CR02, a series of edge switches 400 exist at specific points on the peering path between them. Each of these switches has a limited capacity relative to the backbone as a whole, and congestion events may occur between these switches.

Figure 6 shows some example threats and issues that exist on the Internet. The network data path has been simplified in the figure to provide an overview of connectivity and to highlight threats from endpoint devices (EPDs) and other threats from intermediate devices.

A request from a host client device C002 to retrieve content from a host server device 207 should take the path P109->P105->P103->P102->P101 and be transmitted via the Internet 101 to CP01->CP02->P205->P207. A legitimate Internet data center (IDC) may have a load balancer that sends traffic to a healthy host server 207 (via P207) or an infected host server 206 (via P206). An infected host server may send malware, viruses, or other objectionable content back to the client device C002.

Another threat is redirecting legitimate traffic to the spoofed host server 114. Traffic should follow the path between C02 and 207 described above, but the spoofed server can siphon legitimate traffic away. Traffic will still follow a path such as P109->P105->P103->P102->P101 and pass through Internet 101, but rather than traveling to the legitimate server via CP01, it will instead travel to the spoofed server 114 via P113 and P114.

Spoofed servers can be designed to conduct phishing attacks for confidential information, credentials, or other data by appearing to internet users like legitimate servers. Regular users cannot distinguish legitimate servers from spoofed servers. A third party can also use spoofed servers to block legitimate traffic from reaching clients by sending back invalid traffic or altered content.

Public Domain Name System (DNS) servers are available on the Internet to be queried by client devices to convert Uniform Resource Locators (URLs), such as the domain name www.thisdomain.com, into numeric IP addresses, such as IPv4 or IPv6 addresses, so that traffic from a host client device can find its way to a host server device.

If a DNS server such as 212 or 116 is poisoned 112 or spoofed 114, the converted numeric IP address may be the source of incorrectly directed traffic to an illegitimate or compromised destination device. Another way DNS can be compromised on the Internet is if a device does not deliver results or delivers incorrect results and operates improperly. Propagating changes from the primary DNS registration server to the DNS servers also requires clear and valid connectivity, otherwise the index results may become outdated or erroneous. An example of how to protect and secure DNS lookups will be illustrated using a secure DNS (DNSSEC) server 110 and its connectivity via P19. This relies on the ability of client devices to connect to the DNS server 110 and have their "handshake" not be interrupted.

Even when both the host client and host server devices are operating correctly, because the Internet is unencrypted, there is a very real risk that a sniffer or interception device 204 inserted at an intermediate point in the communication path to a host server, such as mail server 203, could intercept and capture data. Although traffic destined for mail server 203 should flow from Internet 201 to POP 202 to P203 to mail server 203, the sniffer or interception device 204 will cause the traffic to pass through P204 and to P222 via P204. Detecting such interference is very difficult unless the IP address of a hop in the communication path can be positively identified as belonging to a malicious device, rather than another router that is part of the Internet infrastructure.

A growing threat comes from BOT networks consisting of a group of infected devices 213, 215, 216 controlled by a command and control (C&C) server such as 214. These devices can collectively perform bulk attacks, such as distributed denial of service (DDoS), in which host server devices may be overwhelmed by too many requests flooding into their capacity, causing requests from legitimate host client devices to become slow to parse or completely fail to parse.

BOT networks can also be used to carry out covert hacking attacks coordinated by a C&C server, so a large number of different IP addresses attempting dictionary password attacks will be more difficult to completely block than the same attack from a single IP address.

BOT networks are also a distribution mechanism for spam emails, phishing emails, malware distribution, and other malicious purposes.

National firewalls, such as the 304, block the free flow of information. These firewalls can be used as censorship tools to block traffic deemed objectionable by the state. They can also be used as interception devices to steal industrial, commercial, or other secrets. Depending on the time of day, total internet traffic, and the health of these national firewalls, traffic passing through them may experience latency or packet loss, be shaped to maximum bandwidth, creating bottlenecks, or all or a combination of these issues.

The example embodiments mentioned above describe only some of the problems and threats. Many other threats exist, and new threats emerge from time to time.

Figure 7 illustrates the resolution and delivery of region-specific content by a content delivery network (CDN). A content delivery network (CDN) can provide significant advantages in terms of speed and flexibility and provide load balancing when delivering content to clients. A content request 7REQ000 flows from a host client (C) 7100 to a host server (S), and a response stream 7RESP002 for content delivery is returned from the host server (S) to the host client (C) 7100 as a file, data stream, or data chunk.

Host Client (C) 7100 can be a device such as a laptop, desktop, phone, tablet, or other device that acts as a client in a client-server (CS) relationship with a host server (S). The host client (C) requests access to content provided by the host server (S) via a uniform resource locator (URL).

The POP 7102, DNS server 7104, and Internet 7300 operate in the conventional manner as described above.

In the context of a CDN infrastructure, CDN mapping tags 7200 coordinate operations with CDN control servers 7202. CDN mapping tags 7200 and CDN control servers 7202 determine the region in which the host client device is located and which CDN server the host client should connect to for content provided. For example, if host client 7100 is in region A, it will be routed to CDN server 7504 in region A via server POP 7404 in region A. Host client 7100 in region B will connect to CDN server 7502 in region B via server POP 7402 in region B. Host client 7100 in region C will connect to CDN server 7500 in region C via the POP of a server in region C's server POP 7400.

The initial CDN mapping tag 7200 lookup via 7P00, via POP 7102, via 7P004 may be very fast, or may take a relatively long lookup time if the CDN mapping tag server is located in an area far from the client device. Once the lookup is complete, traffic will flow to the nearest and or best available CDN server via 7P008.

For the purposes of this diagram, a region is defined as a geographic area that is distinct from another. It doesn't necessarily represent a large area, but it can be. It can also represent a large distance from one region to another, or they can be very close to each other. The key is that clients in one region will receive content from CDN servers in that region, not from another.

In this example embodiment, the content of each region is different from the content of other regions. Between CDN servers 7500, 7502 and 7504 and origin server 7600 are content region servers 7700, 7702 and 7704, which publish the region-specific content to the CDN servers in each region, which then provide it to clients in their corresponding regions.

When a client 7100 in one region, such as region C, wants to obtain content provided by a server 7502 or 7504 from another region, no matter what they do, they are only provided with content from the server 7500 in their region. They cannot access other content, even if they try to force a connection to a content server in the region from which they expect to receive content. They continue to obtain content from their region without making any selections. The local DNS lookup 7104 resolves to the IP address of the CDN server 7500 in their region. This can be because the global IP address only maps to the CDN in their region (in the case of a global IP) or for another reason. As a result, the client may be geographically blocked at 7P404 or 7P402.

Normal connections via 7P008 based on the current geographic location are not blocked, and traffic flows in a manner that enables the host client 7100 to receive content for that geographic location via the host server 7500.

For destinations other than the current geographic locations 7502 and 7504, traffic is stopped at 7P402 and/or 7P408 and the host clients are denied content from the remote geographic destinations. Depending on the configuration and policies of the CDN control system 7202, they may be forced to connect to a server in their current location 7500 and receive no content, an error message, or simply unwanted content.

Figure 8 illustrates the operation of a proxy server. A content request or push 8REQ000 is streamed from a host client (C) to a host server (S) as a file, data stream, or data block. Content delivery 8RESP002 is returned from the host server (S) to the host client (C) as a file, data stream, or data block. A host client 8100, a client device in a client-server (CS) relationship with a host server 8500, requests access to content from a remote server (S) via a uniform resource locator (URL). This request passes through a gateway (GW) device 8102 running proxy client software. In other cases, the proxy client software can run directly on the host client 8100. The proxy client software connects to a proxy server 8306 via an encrypted or unencrypted tunnel, connects from the gateway GW 8102 to a point of presence (POP) 8200 via path 8P02, connects to a WAN 8308 (part of the Internet) via path 8P04, and connects to a proxy server 8306 in a remote area via path 8P6. Traffic exits the proxy server 8306, enters the open Internet 8300 via path 8P16 and connects to the POP 8302 via path 8P12 and then connects to the host server 8500 in the target area via path 8P10.

The host server sees the traffic as coming from the IP address and geographic location of the proxy server. If the IP is in the same region defined by the server in the target region, the desired content will be provided. To help with this localization, the proxy server will typically connect to a DNS server 8404 in the same region as the proxy server.

Figure 9 shows a point-to-point tunnel TUN established between two gateway devices 9A1 and 9B1. Each device 9A1 and 9B1 is located at the edge 9EDGE-1 and 9EDGE-2 between the Internet EH3 to EH15 and their corresponding local area networks (LANs) 9A2 and 9B2.

The baseline from EH1 to EH17 depicts the number of hops from point to point. The number of hops from EH3 to EH15 is hypothetical and provided for illustration purposes, and the number of hops in a real-world connection path may be higher or lower. A client using tunnel 9TUN will see approximately four or five visible hops from 9A2 to 9A1 to 9TUN to 9B1 to 9B2.

This example embodiment describes a scenario in which LAN 9A2 is connected to the network of one Internet Service Provider (ISP) 9ISP-1 via its gateway 9A1, and LAN 9B2 is connected to another Internet Service Provider (ISP) 9ISP-3 via its gateway 9B1. This example embodiment further illustrates that ISP-1 is not directly peered with ISP-3. Both ISP-1 and ISP-3 require that their network traffic in both directions must pass through the network of another Internet Service Provider (ISP) 9ISP-2. The interconnection between ISP-1 and ISP-2 is defined as peering point 9PP-01, and the interconnection from ISP-3 to ISP-2 is defined as 9PP-02.

The point of this example embodiment is to illustrate that on the internet, third-party ISPs or equivalent providers, such as backbone or backhaul providers, typically transport traffic for other ISPs. ISP-1 or ISP-3 has little to no control over how ISP-2 transports its own traffic. While ISP-1's customer 9A2 can complain directly to their provider 9ISP-1 about service issues, and ISP-3 can complain directly to ISP-3, if the problem is with ISP-2, there's little ISP-2 or ISP-3 can do to directly impact ISP-2.

Potential congestion points can occur on any device, but because 9PP-01 and 9PP-02 are peering points, they are areas of concern. Control over the routing and quality of service of the overall connection is limited. Therefore, point-to-point tunnels may struggle to maintain a high-quality, stable connection over distance, especially when some traffic is routed through a third-party network.

10 shows the relationship of security features between device scope 1080 and system-wide scope 1090. It also indicates communication scope 1098 and device collaboration 1089.

With respect to the device scope 1080, the GVN protects the client privacy of its data, network data flows, credentials, peer-to-peer information, and protects physical devices from intrusion, proprietary code contained therein from tampering or theft, and other threats.

System-wide 1090 needs to protect against intrusion or other malicious traffic such as DDoS attacks, prevent misuse, perform routing around suboptimal devices or paths, balance and distribute load, and prevent exhaustion of resources, IP addresses, or other global issues.

Communication scope 1098 focuses on the traffic path through the GVN, primarily through traffic tunnels (TUNs). It also covers the entry and exit points (EIPs) between the GVN's external and internal networks. It protects against traffic hijacking, man-in-the-middle attacks, poisoned information sources (such as bad DNS servers), and other threats. Furthermore, testing the quality and properties of each network segment enables the GVN to understand the complete path QoS and circumvent issues.

Device collaboration 1089 security features are in place to protect the operational integrity of each device within the GVN. Secure return channels, anti-intrusion mechanisms, DNS security nets, various database protections such as rotation keys, neutral API mechanisms (NAPIM), automated testing, updates, peer-to-peer relationships, authentication, and other modules ensure that system integrity is maintained.

Figure 11 shows the information flow between devices in the global virtual network. The central repository consisting of the database B200 and the file storage HFS200 resides on the central server (SRV_CNTRL) 200.

The communication paths between devices labeled P### may represent API calls, database replication, direct file conversion, a combination of database replication such as via API calls, or other forms of information exchange. The thicker lines 11P200100, 11P200300, 11P200500, 11P100200, 11P100300, 11P10011500, 11P300200, 11P300500, and 11P500200 represent communications between GVN devices that have peer pairs and privileged relationships with each other.

The figure shows peer-to-peer communication in a round-robin pattern from SRV_CNTRL 200 to EPD 100 via 11P200100, from SRV_CNTRL 200 to SRV_AP 300 via 11P200300, or from SRV_CNTRL 200 to other devices 11500 via 11P200500. EPD 100 communicates with SRV_CNTRL 200 via 11P100200, with SRV_AP 300 via 11P100300, and with other devices 11500 via 11P1001500.

In some cases, devices may share information loops, such as EPD 100 may request information from SRV_CNTRL 200 via 11P100200 , and the request will be sent back to EPD 100 via 11P200100 .

In other cases, one device may report information related to other devices, such as SRV_AP 300 reporting to SRV_CNTRL 200 via 11P300200, and SRV_CNTRL 200 then sending the information to EPD 100 and SRV_AP 300 via 11P200100, and sending the information to other SRV_APs 300 other than the reporting SRV_AP 300 via 11P200300, and sending the information to other devices 11500 via 11P200500.

In other cases, a full loop is not required, such as sending logging information from a device such as EPD 100 to SRV_CNTRL 200 via 11P100200 without forwarding this information further. However, the logging information may then be moved from the repository on SRV_CNTRL 200 to the long-term logging storage server 11500 via 11P200500.

There is a direct link 11P100300 between the device EPD 100 and the SRV_AP 300. The direct link 11P300500 is from the SRV_AP 300 to another device 11500. A direct link involves communication between devices without the involvement of the SRV_CNTRL 200.

The information pushed from SRV_CNTRL 200 can be RSS feed information or other types of information published via 11P 306. The API from SRV_CNTRL 200 can be a traditional API transaction or a RESTful API call that issues a request via 11P 302REQ and receives a response via 11P 302RESP. The push information and API elements presented are intended to illustrate devices that do not share peer-to-peer relationships, privileged status, and/or similar system architectures with GVN devices.

Figure 12 depicts a stack for supporting automation of some devices in a GVN. Specifically, this diagram shows the modules required for automated device collaboration and networking, as well as operating system (O/S) management.

EPD 100 is an endpoint device. SRV_AP 300 is an access point server located in the target destination area. SRV_CNTRL 200 is a central control server accessible by both EPD and SRV_AP as well as by other devices that can support the graphics destination mechanism or other GVN modules, components or servers.

Each device, EPD 100, SRV_AP 300, and SRV_CNTRL 200, stores information about itself in a local information repository in the form of lists, files, database tables, records, and other means. This repository also includes information about peer device relationships, stored logging, and other relevant operational information. SRV_CNTRL 200 also has additional storage capabilities and is used to provide information to other devices associated with it and/or to peer devices that may be connected to it, so as to assess the current status and provide guidance similar to centralized control, such as publishing server availability lists and other functions. A neutral API mechanism (NAPIM) can be used to send information between devices and their connected peers and can also be used to update the API itself.

The database S293 on the SRV_CNTRL 200 serves as a repository for information about the device itself, as well as a central repository for other devices. There may be many different SRV_CNTRL 200 servers in many locations, acting as a multi-master device. Each database can store specific information, including tunnel information, peer information, traffic information, cache information, and other information. Security and other aspects are managed independently by each device, including heartbeat functionality, trigger scripts, and other mechanisms.

The GVN software D196, D296, D396 includes a tunnel builder/manager, a virtual interface manager, automatic intelligent routing, a testing module, security, logging, and other functionality. Figure 11 also shows operating system (O/S) level packages D195, D295, D395 and includes hardware and software drivers, drivers, installed packages, including their dependent software packages, and other items built on top of the system hardware components.

FIG13 shows a GVN topology including a backbone segment on the Internet or dark fiber. International Patent Application No. PCT/UJS15/64242, entitled "SYSTEM AND METHOD FOR CONTENT RETRIEVAL FROM REMOTE NETWORK REGIONS," discloses a feature in which multiple files are aggregated into larger files and sent from one geographic region to another via file transfer via "chain caching." To achieve this advantageous feature, the file transfer needs to be as fast as possible. As a method of transmitting groups of multiple data payload "files," the information slingshot method of the present invention moves larger data blocks from one end of the world to the other more quickly than prior art methods.

13 , multiple zones are shown: LAN Zone 0 (ZL00), LAN Zone 1 (Z110), Internet Zone 0 (ZI00), Internet Zone 1 (ZI10), Internet Zone 2 (ZI20), Internet Zone 3 (ZI30), Internet Data Central Zone 2 (ZD20), and Internet Data Central Zone 3 (ZD30).

An SRV_BBX 1372 in a zone or zone ZD20 may be connected to an SRV_BBX 1380 in another zone or zone ZD30 via a dark fiber connection 13P220 over dark fiber 13220. The SRV_BBX 1372 writes files directly to a parallel file store PFS 1382 via remote direct memory access (RDMA) via 13P220, bypassing the SRV_BBX stack 1380, and via path 13P82. The SRV_BBX 1380 uses the present invention to write files directly to a parallel file store PFS 1374 via 13P220, bypassing the SRV_BBX stack 1372, and via path 13P74 via remote direct memory access (RDMA).

Path 13P210 may be IPv4 or some standardized Internet protocol over which traffic flows from SRV_AP 13300 to SRV_AP 13310 and/or from SRV_AP 13310 to SRV_AP 13300 via path 13P210 over the GVN via a tunnel or other type of communication path.

This demonstrates that various types of network structures can be combined into a larger network tapestry. These structures can be seamlessly woven together, as described in U.S. Provisional Patent Application No. 62/174,394. This can be a standalone approach or integrated as a network segment within a larger network path composed of multiple network segments. This example embodiment illustrates the topology of a global virtual network (GVN), its multiple devices, communication paths, and other embodiments. It shows how various geographic areas, regions, or districts can be linked together through various types of paths.

Figure 14 illustrates a distributed firewall (FW) in a cloud implemented by a GVN. Due to the nature of the GVN's topology, device-to-device communication, and secure traffic paths, the firewall mechanism can be cloud-based and can also be virtualized. With traffic flowing to and from the GVN via an entry/exit point (EIP) via the open internet 14000, a cloud firewall (CFW) load balancer 144LB can exist, capable of distributing cloud firewall resources such as 144-2, 144-3, and the like.

This on-demand scalability provides numerous advantages for GVN clients. By reducing the attack hit rate of impending threats in the cloud, the client's "last mile connectivity" is not affected. This cloud firewall, combined with the control node and analyzer, enables the FW in the attacked area to perceive the nature, source, signature, and other characteristics of the attack, so that the cloud firewall can be aware of and prepare to defend against the attack when the target shifts. In addition, information about past and current attacks can be shared with other CFW instances via the GVN's Neutral API Mechanism (NAPIM), enabling global threat awareness. This also provides the advantage of running multiple types of FW mechanisms simultaneously, as described with reference to Figure 15.

Figure 15 shows a multi-perimeter firewall (MPFW) in the cloud driven by a global virtual network. The GVN tunnel 15TUN0 is over the top (OTT) of the Internet between the endpoint device (EPD) 15100 and the access point server (SRV_AP) 15300 next to the EPD 15100.

The three perimeters indicated in this example embodiment are: 15M1, which represents the boundary between the client location and its link to the Internet; 15M2, which is the boundary at the data center in the cloud close to SRV_AP 15300; and 15M3, which is another boundary at the same data center as SRV_AP 15300 or at another location close to SRV_AP 15302.

Tunnel 15TUN2 is similar to 15TUN0 but differs in one respect, namely, the personal endpoint device (PEPD) 15130 it connects may be a mobile device and therefore connected to SRV_AP 15300 via a public access wireless or wired or other network for integration into the GVN.

Each SRV_AP 15300 and SRV_AP 15302 may represent one or more SRV_AP devices that may be simultaneously connected to the EPD 15100 and/or EPD 15130 via one or more tunnels.

In this example embodiment, three types of firewalls are described. FW Local 15442 is an example firewall that a client can use to protect its local area network (LAN) from Internet-based threats. This is typically located between EPD 15100 and LAN 15000. This FW 15442 can provide features such as IP address and port blocking, forwarding, and other functions. The other two types of firewalls shown are FW SPI 15446 located at 15M3, which provides stateful packet inspection (SPI), and FW DPI 15444 located at 15M2, which provides deep packet inspection (DPI).

The difference between SPI and DPI involves a trade-off between performance and visibility. SPI examines packet headers for malicious information or patterns, or matches IP addresses, ports, or other information from a list of known threats to the current packet flow. As the name suggests, DPI looks deeper into the entire packet and, in the case of multi-part, multi-packet transmissions, compiles a series of packets to gain further insight into the transmitted data.

All firewalls can be configured to investigate and apply rules to incoming and outgoing traffic, and provide other related functionality.In many cases, clients will have to choose between the efficiency of SPI and the thorough but resource- and time-consuming requirements of DPI.

GVN provides the opportunity to distribute these FWs at multiple points in the cloud and for various types of firewalls to operate in close proximity to each other without hindering traffic flow.

By positioning FW SPI 15446 at 15M3, the closest edge of the Internet 15302, via remote EIP 15310, it is possible to protect against large amounts of attack traffic originating from known source IP addresses or with identified malicious headers. Traffic flows from SRV_AP 15302 via 15T10 to FW SPI 15446 and back via 15T12. FW SPI 15446 can be a CFW load balancer with significant demand resources (see Figure 14). The SRV_AP at 15M3 can be a multi-homed backbone with significant capacity. Thus, attacks can be captured at the first perimeter, protecting bandwidth within the GVN.

At the next boundary 15M2, FW DPI 15444 can either allow all traffic to pass through or simply receive a copy of the traffic from SRV_AP 15300 via 15T20, and may or may not return the traffic via 15T22. The key point is that the DPI feature can be a trailing-edge indicator that allows specific traffic to pass through but analyzes and records the results. This FW DPI 15444 can also be a CFW, which can load balance when needed, using resources provided on demand, to cope with large-scale events when needed, without requiring individual clients to handle or bear the cost burden of maintaining the infrastructure during normal times.

Information from FW SPI 15446 and FW DPI 15444 is shared with each other via an internal communication path 15P6, which can be transmitted by the GVN's NAPIM, through a GVN tunnel, through a GVN return tunnel, or via other communication pathways. Each FW mechanism also shares information with the GVN's Central Control Server (SRV_CNTRL) 15200. This information can be relayed to other FW SPIs and FW DPIs worldwide, so that attack vectors, sources, payloads, and other relevant information are available in the database, allowing SPI and DPI checks to have a reference point for comparison. This achieves increased efficiency at scale, as the global distribution of information provides an additional safety net.

Capturing malicious traffic outside the client LAN and in the cloud protects the client's last mile Internet connectivity from being saturated with unwanted traffic.Offloading traffic to a scalable CFW also provides numerous advantages to the client.

The local FW 15442 can be a standalone device, a software application (APP) running inside the EPD 15100, or other types of FW devices.

The FW SPI 15446 and FW DPI 15444 appliances, along with related devices such as load balancers, cloud firewalls, or other appliances, can be custom-built or available off-the-shelf from other vendors to create the best combination for the client. These appliances must be able to receive and forward traffic, identify threats, and most importantly, communicate threat findings, as well as receive threat profiles and other information from other devices.

As threat data accumulates, it can analyze the content, patterns, attack vectors, and other information collected by the FW. This analysis can provide the basis for applying heuristic analysis to new potential threats.

This can be achieved solely by the Secure Network Optimization (SNO) service of the GVN or a similar network consisting of related devices connected by both secure tunnels and communication paths.

Figure 16 shows a logical view of the software architecture of three types of network devices working together as part of a global virtual network (GVN). As shown in the figure, the software and hardware can be distributed within the network device and can be distributed across different circuit boards, processors, network interface cards, memory and storage devices.

One of the network devices is an endpoint device (EPD) 100 , another of the network devices is a central server (SRV_CNTRL) 200 , and a third device is an access point server (SRV_AP) device 300 .

EPD 100 is connected to SRV_AP 300 via an encrypted tunnel described as a communication path, which can be via encrypted tunnel SYSC04 to point of presence (POP) SYS406, through communication path SYS06 to WAN SYS400 to communication path SYSCP10 to POP SYS402 to communication path SYSCP12. The path through WAN SYS400 can also be through the regular unencrypted Internet.

Each device EPD 100 and SRV_AP 300 may also be connected to the SRV_CNTRL device 200 via a communication path SYSCP08.

The software architectures of the EPD 100 and SRV_AP 300 are very similar to each other, differing in the role each device plays in operation and in some modules.

At the lowest level of each device is the memory (RAM) 106, 206, 306, the processor (CPU) 102, 202, 302, and the network interface (NIC) 108, 208, 308. All of this is at the hardware level. The operating system (O/S) 110, 210, 310 can be a Linux system or an equivalent system such as Debian or other systems. The operating system describes the data packages and configurations used for routing, hosting, communication, and other system-level operating software.

Above the operating systems 110, 210, 310 lies the system software layer 112, 212, 312 of the global virtual network (GVN) operating system. Custom commands, system modules, managers, and other components all operate here, along with other components of the GVN. Each type of device in the GVN can have some, all, or different portions of these parts of the system software layer, depending on its role.

In this example embodiment, the database modules Db 120, 220, 320 and the hosting modules 122, 222, and 322 are configured for monitoring, sending, processing, storing, retrieving, and other related basic level operations for the GVN Neutral API Mechanism (NAPIM), graphical user interface (GUI), and other server-side script hosting sites. The database 120, 220, 320 (Db) modules can be MySQL or equivalents such as MariaDB, and the hosting modules 122, 222, and 322 can be Apache and PHP scripts or other types of hosting languages. Command line scripts are also used and can be written in Bash, C, PHP, Pearl, Python, or other languages.

The billing modules can collaborate and share information about billing through consumption models, such as the amount of data consumed by tunneled traffic. Accounting modules ACC 132, 232, 332 operate on EPD 100, and SRV_AP 300 has a corresponding billing module. Both modules can provide financial information to reporting screens, providing payment forms, emailed reports, and other financial data generated by the GVN.

The SRV_CNTRL 200 has a repository manager 238 that handles billing information, tunnel manager information, and other data that can be used by various devices in the GVN. The repository manager 238 also handles the coordination of sharing peer information, credentials, and other information with independent devices connected to other API peers through the GVN's Neutral API Mechanism (NAPIM).

EPD 100 has API module 130, SRV_CNTRL has API module 230 and SRV_AP 300 has API module 330. To simplify the explanation of this exemplary embodiment, only one API module is described for each device. In practice, depending on the function of the device in the GVN, the device can play the role of a combined client and server.

The cache manager on SRV_CNTRL 200 manages the master index of multiple chained caches distributed across many devices in the GVN. The compression engine 136 on EPD 100 and the compression engine 336 on SRV_AP 300 manage the compression and decompression of data stored in files, DB tables, or for streaming data.

The Advanced Smart Routing (ASR) 150 module on the EPD 100 handles the routing of traffic from the EPD 100 via the GVN to the optimal egress point at the destination.

The Remote Retrieval BOT 311 on the SRV_AP 300 is the core component of the Geographic Destination Mechanism (Geo-D).

The DNS manager 254 on the SRV_CNTRL 200 manages the master DNS index that can seed DNS servers on various GVN devices, such as seeding the DNS 154 on the EPD 100 .

The logging manager on SRV_CNTRL 200 manages local logging and logging shared by devices to the repository via API calls. The logging manager in this example embodiment is empowered to log operational events, API actions, and transactions, and has other roles and processes for various aspects of GVN operations.

The local cache 152 on the EPD 100 and the local cache 352 on the SRV_AP 300 cache the data locally.

The GVN manager 272 operates on the SRV_CNTRL 200 to control the operation of the various components of the system on the SRV_CNTRL 200 and other devices of the GVN.

The local DNS server and cache 154 on the EPD 100 and the cache 354 on the SRV_AP 300 allow DNS lookups to be cached for fast local retrieval. The DNS 154 and 354 can be completely flushed, individual entries can be cleared, or a timeout can be set to delete retrieved lookups after a certain period of time.

EPD 100 is equipped with a Content Delivery Agent (CDA) 158, a component of Geo-D. SRV_AP 300 is equipped with a Content Pulling Agent (CPA) 358, also a component of Geo-D. CPA 358 works with BOT 311 on SRV_300 to pull content from remote zones using a local DNS 354 seeded from that zone. CPA 358 uses tunneling, caching, and other advanced features of GVN to send the fetched content to CDA 158.

Firewalls (FWs) (not shown) on the EPD 100, on the SRV_CNTRL 200, and on the SRV_AP 300 operate to protect access to the devices and communication paths between the devices and others.

Connectivity managers (not shown) on EPD 100 and SRV_AP 300 manage tunnels and other device-to-device communication paths between devices. The compression manager on SRV_CNTRL 200 215 manages local compression and also collaborates with compression engine 136 on EPD 100, compression engine 336 on SRV_AP 300, and compression engines on other devices in the GVN. Routing on the EPD collaborates with ASR 150, Geo-D, and other elements to manage traffic routing.

The structure of the database tables in SDB100, SDB200, and SDB300 is equivalent for device operations, but the data in each database table is specific to the device type, and each device has a unique identifier for the specific device. On SR V_CNTRL200, the repository database SDB202 is used to store unique information for all devices, and the repository management library 238 can use this information to communicate API credentials, tunnel information, or other information to the device.

Each device stores information about the device itself and its peers, API peer information, transaction lists, queue data, and other information. In addition to the uses described, the method and database have other uses, but for simplicity of explanation, this example only covers a few exemplary core functional elements.

Topology

A GVN using a hub-and-spoke topology with backbone segments and octagonal routing is shown. Figure 17 shows the network topology of the GVN in two different regions, 17-RGN-A and 17-RGN-B, and how the regions are connected via paths 17-P0A and 17-P0B through a global connection 17-RGN-ALL. Furthermore, Figure 17 shows the hub-and-spoke connectivity within each of the two regions. Figure 17 is similar to Figure 15 but adds multiple entry/exit points (EIPs) in each region in the form of additional spokes of the hub-and-spoke model.

SRV_BBX 17-280 and SRV_BBX 17-282 are backbone switching servers and provide global connectivity. SRV_BBX may be one or more load balancing servers serving as global links within a region. Access point servers (SRV_AP) 17-302, 17-304, and 17-306 in 17-17-RGN-A are connected to SRV_BBX 17-280. Central control server (SRV_CNTRL) 17-200 serves all devices in the region and may be one or more multi-master SRV_CNTRL servers. Endpoint devices (EPDs) 17-100 through 17-110 connect to one or more SRV_AP servers via one or more parallel tunnels.

The diagram also shows multiple entry/exit points (EIPs) 17-EIP420, 17-EIP400, 17-EIP430, and 17-EIP410 in each region as additional spokes in a hub-and-spoke model, with paths to and from the open internet. This topology provides EPD connectivity to EIPs in remote regions through the GVN. Alternatively, this topology supports EPDs connecting to EIPs in the same region, to EPDs in the same region, or to EPDs in remote regions. These connections are securely optimized through the GVN.

Figure 18 illustrates the backbone connections between some GVN global nodes and their corresponding service areas in North America, Europe, and Asia. As indicated in the legend box in the lower right corner of Figure 18, each area described herein from a networking perspective is described as a global node. Global nodes are connected to each other via high-performance network links. The lower the latency between each point, the faster the information transfer.

The two rings around the global node represent the types of connectivity quality zones within a radius from the center of the source information. This is for illustrative purposes only, as the size and shape of these zones are determined by many factors. However, the two zones can be distinguished from each other, with the closest zone being the high-performance zone and the other zone being the best service zone.

The further a query client or server or other type of device is from the global node, the longer it takes for information to flow, and at some point the distance becomes so great that the QoS degrades so that the device is no longer in the high performance zone and is now in the best service zone.

If the QoS drops below a certain threshold, then the device is outside the optimal service area and therefore the distance between the device and the global node is too great that the benefits provided by the GVN, other than security, may be uncertain.

FIG18 shows SJC 18-01 in San Jose, California, USA, JFK 18-02 in New York, New York, USA, AMS 18-11 in Amsterdam, Netherlands, NRT 18-21 in Tokyo, Japan, and HKG 18-22 in Hong Kong, China. Many other locations around the world require placement of important global nodes, but for simplicity of illustration, only a few locations are shown for illustrative purposes.

Figure 18 also shows representative paths between various global nodes, such as between JFK 18-02 and AMS 18-11. In reality, there are many paths between two points representing submarine cables.

Figure 19 illustrates the connectivity between various devices within the GVN, indicating multiple connection paths from devices in the spokes to the hub. The placement of SRV_BBX (backbone exchange servers) 19-800 and 19-810 is based on the client's location relative to the optimal Internet Data Center (IDC) for interconnection, serving the target region while connecting to global locations via paths 19-BB2 and 19-BB6.

The SRV_BBX serves as the hub for the region it serves. Hubs are connected to each other via over-the-top (OTT) tunnels over Ethernet links in the Internet, tunnels over direct Ethernet links, unlimited broadband over fiber, unlimited broadband over Ethernet, or other forms of connectivity between regions. Each hub serves multiple SRV_AP servers, such as 19-302, 19-306, and 19-308, which serve one region within the global region. SRV_APs 19-312, 19-316, and 19-318 can serve another region within the global region.

Endpoint devices (EPDs) such as 19-100 through 19-128 will connect to the most appropriate SRV_AP server relative to their location, network connectivity, peers, and other relevant factors. These factors are constantly changing, and therefore multiple tunnels to multiple SRV_AP servers are always maintained by the EPD. Each EPD is connected to various (one or more) SRV_AP servers simultaneously.

There are entry and exit points (EIPs) at EPDs, SRV_APs, and other locations where traffic can leave the GVN and enter the Internet or enter the GVN from the Internet, and the GVN protects and optimizes the traffic as far as possible.

SRV_AP devices such as SRV_AP 19-308 and SRV_AP 19-318 are also connected to each other through tunnel paths such as 19P60 so that two EPDs such as EPD 19-110 can connect with EPD 19-128 via paths 19P22 through 19P60 through 19P58.

The central control server (SRV_CNTRL) 19-200 is connected to multiple devices, such as the SRV_AP 19-302 via path 19P62 for Neutral API Mechanism (NAPIM) information exchange. The EPD is also connected to the SRV_CNTRL 19-200 via the NAPIM path. To keep this example embodiment relatively simple, the NAPIM EPD to SRV_CNTRL path is not shown.

The NAPIM information exchanged between the SRV_CNTRL and various devices can be used to share usage statistics, tunnel establishment information such as IP addresses, ports, protocols, security credentials, certificates, keys, and other information to achieve automatic and secure operation of the GVN.

Figure 20 illustrates how GVN modules and devices interact. A Global Virtual Network (GVN) consists of various devices that operate independently and collaborate with other devices. While each device's role may differ based on its type and underlying functionality, they all share similar code bases, database schemas, and other architectural elements.

Infrastructure is installed in an area to support the operation of EPDs and PEPDs. Devices such as endpoint devices (EPDs) 100, portable endpoint devices (PEPDs), and endpoint hubs (EPHs) connect various LANs, PANs, and other networks to the GVN via tunnels to access point servers (SRV_APs) 300. Each device has its own locally managed database.

Redundancy is provided by having multiple primary SRV_CNTRLs and multiple servers of each type in each region for other server types. A central data repository resides on the Central Control Server (SRV_CNTRL) 200. The SRV_CNTRL's job is to connect to various devices via the GVN's neutral API mechanism. API calls via the GVN's NAPIM are routed via path 20P02 for inter-device communication, such as EPD 100 to SRV_BC 20-502. The device_ID and registration/region mappings in the Db repository on the SRV_CNTRL allow API peers to manage relationships, generate appropriate Server Availability Lists (SALs), and receive logging. This allows for efficient management of relationships and connections with SRV_AP and GW servers.

The backend servers and infrastructure devices of the GVN include a backchannel server (SRV_BC) 20-502; a secure boot server (SRV_SB) 20-504; an authentication, authorization, and accounting server (SRV_AAA) 20-508; and a logging server (SRV_LOG) 20-516, among others.

Gateway servers and other devices connect to the SRV_CNTRL 200 via connector 20AD0 and to gateway devices via the "all devices" hub 20AD2. This may include a gateway email server (SRV_GW_Mail) 20-510, a gateway server for financial transactions (SRV_GW_FIN) 20-518, and/or a gateway server for third-party connections (SRV_GW_TPC) as a class of other SRV_GW_* 20-512.

A specialized gateway server can be tailored to that function and the way it provides protection. By authorizing an email gateway server, it can be set up as a secure email sender and receiver. This will require configuration, maintenance, and monitoring of its operation. However, at the same time, no additional servers are needed to handle email, freeing up the management burden of those devices. All devices can forward emails via a data payload sent to the API by an action call requesting to send an email. Flags in the payload can indicate whether the email should be sent immediately, at a specific time, or with what priority. Other settings can govern how it is sent. SRV_GW_EMAIL will receive these data payloads and add them to its email send queue, and the email manager will handle when and how the email is delivered and will log the event accordingly. Bounces, replies, and other incoming emails can also be handled by a peer server type SRV_GW_EMAIL.

The logging server and other devices may also be accessed by the GVN devices via 20AD4.

FIG21 shows additional details about how the GVN modules and devices interact. These additional details include communication paths, such as 21Q00 from SRV_BC 4-502 to SRV_CNTRL 200, for reporting information from the backchannel server to the central control server. The key point is that while a GVN device will need information about itself, its peers, its connectivity options, and other information to operate, sharing performance and other data with SRV_CNTRL 200 and/or other devices provides a holistic understanding of the larger system. This constant feedback loop allows for automatic adjustments and learning on the fly, enabling better decision-making.

Figure 22 shows the topology and connectivity of GVN modules and devices and how they interact with other devices on the Internet. The communication paths shown in Figure 22 include the external path (PE), the tunnel path (for traffic) (PT), the control path (CP), the encryption system path (ES), the API communication path (PA) between GVN devices, and more communication paths.

The central server (SRV_CNTRL) 200 includes a file repository and database that stores important system information. The SRV_CNTRL is able to connect to all GVN devices via PA paths for API communication. The endpoint device (EPD) 100 is a network access point between the local area network (LAN) and the Internet via various parallel potential communication paths.

Advanced Smart Path (ASR) within the EPD sends local traffic to the nearest Internet connection 22-010 via path 22-PE00 to point of presence (POP) 22-020 to 22-PE02. A reverse channel server (SRV_BC) 22-502 connects to the EPD 100 via a reverse channel connection from 22ES04 through 22-010, via 22ES02 to 201, and into the EPD 100 to 22ES020. The ES## path is a tunnel path that encrypts the control path and is independent of the transport traffic.

EPD 100 maintains multiple tunnels to each of multiple access point servers (SRV_APs), namely, SRV_AP 300 via 22PT00 and 22PT02, SRV_AP 22-302 via 22PT04 and 22PT08, SRV_AP 22-306 via 22PT10 and 22PT12, and SRV_AP 22-308 via 22PT14 and 22PT16.

The figure is not drawn to scale, but for example, SRV_AP 22-302 and SRV_AP 300 are in the same area and exit the GVN into the Internet 22-012 via path 22PE04 to POP 22-022 to 22PE08 to the Internet 22-012 and path 22PE16 via POP 22-026 to 22PE12 to the Internet 22-012. Both EPDs can perform local DNS lookups on a Domain Name Service (DNS) server 22-402.

Both SRV_AP 22-302 and SRV_AP 300 maintain an API communication path to SRV_CNTRL 200 via 22PA02 and 22PA08, respectively.

The gateway device (SRV_GW) 22-514 is located in the same area as the SRV_AP 22-302 and SRV_AP 300. This can send emails, process financial transactions and other functionality of the SRV_GW device of the GVN.

The SRV_AP 22-306 is connected to the SRV_CNTRL 200 via 22PA10, and the egress point in its area to the Internet 22-014 is via 22PE20 to POP 22-024 to 22PE22 to the Internet 22-014.

The SRV_GW server 22-516 is connected to the SRV_CNTRL 200 via 22PA24 and is connected to the Internet 22-014 via 22PE26 to POP22-024 to 22PE22 to the Internet 22-014.

The SRV_AP 22-304 is connected to the SRV_CNTRL 200 via 22PA18, and the egress point in its area to the Internet 22-016 is via 22PE26 to POP 22-028 to 22PA30 to the Internet 22-016.

The SRV_GW 22-512 is connected to the SRV_CNTRL via 22PA14 and to the SRV_AP via 22PA16. Local traffic from the SRV_GW 22-516 exits to the POP 22-208 via 22PE28 to 22PA30 to the Internet 22-016.

There are other devices within the GVN that perform specific roles, such as the backup server SRV_Backup 22-522 and the logging server SRV_Logging 22-516. These are connected to the SRV_CNTRL via 22PA20 and 22PA22, respectively. They can receive data from SRV_CNTRL 200 or from other devices via the PA## path, which is relayed to SRV_Backup 22-522 or SRV_Logging 22-516.

The described topology of the GVN allows traffic from the EPD 100 to have multiple options for per-region traffic through multiple tunnels to multiple SRV_AP servers. Other devices ensure that information is distributed to various devices for efficient utilization.

Figure 23 shows multiple tunnel connectivity between endpoint devices (EPDs) 100, 23-102, 23-158 and access point servers (SRV_AP) 300, 23-302. These tunnels can be used for client data traffic, internal system data, or other transmissions. This figure further illustrates the connection of global virtual network (GVN) infrastructure devices such as central server (SRV_CNTRL) 200 and reverse channel management server (SRV_BC) 23-502 to other devices in the GVN.

The SRV_BC 23-502 establishes and maintains reverse channel tunnels 23PA02 to EPD 100, 23P018 to EPD 23-102, 23PA06 to EPD 23-158, 23TP50 to SRV_AP 23-302, etc. There may be more SRV_BC servers within the GVN to provide redundancy in case one SRV_BC is inoperative, and also to ensure optimal performance by placing SRV_BC servers in strategic locations close to the devices they connect to.

The EPD 100 connects one LAN 23-002 to various paths taken by data through the GVN, such as via one of three multiple tunnels 23TP00, 23TP02, or 23TP04 to the SRV_AP 300, via path 23PE00 to an exit point to the Internet 23-410.

Another path is from SRV_AP 300 to SRV_AP 23-302 via one of the three multiple tunnels 23TP10, 23TP12, or 23TP14.

The routing option from SRV_AP 23-302 is via 23-382 to the Internet 23-412 exit point.

The external entry point X-IP 305 into the GVN from the Internet 23-412 allows connections by non-GVN devices to address and access the device through the GVN, thereby enhancing the GVN for the duration of traffic carried by the GVN.

Another benefit achieved by the GVN is providing secure tunnel connections with EPDs 23-158 at the locations of service providing partner organizations in the cloud to achieve secure tunneling via the GVN to their servers and related services at the locations of the LANs 23-152.

The LAN-WAN-LAN bridge from LAN 23-002 to LAN 23-012 can communicate via a path from 23-002 to 23CP02 to GWD 23-004 to 23CP04 to EPD 100 to 23TP00, 23TP02, 23TP04 to SRV_AP 300 to 23TP10, 23TP12, 23TP14 to SRV_AP 23-302 to 23TP20, 23TP22, 23TP24 to EPD 23-102 to 23CP14 to GWD 23-014 to 23CP12 to LAN 23-012. All traffic transmitted by this bridge is protected and improved by the GVN mechanism.

Multiple tunnels such as 23TP00 23TP02 23TP04 or 23TP10 23TP12 23TP14 or 23TP20 23TP22 23TP24 between two devices may provide a single communication path by sending traffic along one tunnel, or two or more tunnels may be aggregated together where two or more bound tunnels may transmit traffic as if it were one tunnel.

The SRV_CNTRL 200 with API communication paths between peer pairs and tunnels to other devices can be used for file transfer and data exchange via paths such as 23PA00 to EPD 100 or 23TP30 to 23-302 to 23TP22 to EPD 23-102 or 23PA04 to 23-302 to 23TP60 to EPD 23-158 and other potential options.

In this example embodiment, there are other possible communication paths, and there are more options for communication paths through the GVN. In this example embodiment, all tunnels represent links via the third layer of the GVN, each of which is built on the first layer of the GVN above the Internet.

Figure 24 is a simplified example diagram of how the Internet works today, taking into account hop counts or time to live (TTL) and the paths taken due to peering relationships and associated routing policies.

A0 represents the network of an Internet Service Provider (ISP). A1 to A06 represent points of presence (POPs), and these POPs are further connected to switch devices or client devices to link them to the Internet. This hop and spoke structure shows a cluster of networks within the wider ISP network. Lines with circles in the form of line caps indicate this connectivity. For simplicity, in this example embodiment, the structure of A1, A2, A3 and other POPs does not show links to the last mile network, but these links should be implied. Each POP has its own hub-and-spoke connectivity to a network, such as a local area network (LAN) or an Internet data center (IDC) that enables Internet connectivity via the POP.

H0 is an example of a single-homed ISP, meaning it relies on a single path between it and the Internet. If this path is severed or fails, connectivity from this ISP to the wider Internet is severed.

B0 is an example of a multi-homed ISP showing five connections between itself and other ISP networks; even if one path becomes unavailable, traffic can still flow across the Internet, but through a less direct path.

IX1 and IX2 are examples of Internet Exchanges (IXs), which may be independently linked to each other via backbone or backbone-dedicated connections. IXs are where ISPs and other ISPs can connect to each other at a "meet-me room" or equivalent arrangement for direct network-to-network peering.

Communication paths also exist between the ISP's network and other ISPs' networks, or between them, with IXs or intermediate routers. These backbone communication paths are represented by lines with arrowheads at both ends. Intermediate devices are represented by circles between arrowheaded lines. Backhaul connectivity between IXs is represented by dashed lines with arrowheads at both ends. The paging connector IBH1 is used to indicate international backhaul (IBH), meaning that IX2 also has connectivity with another IX not shown in this example embodiment.

To illustrate the direct efficient connection between ISPs, there are only four intermediate hops from A0 to G0 via the path AX1-1->AX1-2->IX1->GX1-1 and this should be the most efficient route.

To illustrate the detours caused by path failures, if path GX1-1 fails, traffic from H0 or A0 destined for G0 will not be able to pass through GX1-1 via IX1. Instead, traffic must pass through B0 and E0 to reach G0. Previously, traffic from A0 via AX1-1->AX1-2->IX1->GX1-1 required only four intermediate hops. Now, more hops are required: AX1-1 to AX1-2 to IX1 to BX1-4 to BX1-3 to BX1-2 to BX1-1 to B0 to EB-5 to EB-4 to EB-3 to EB-2 to EB-1 to E0 to GE-3 to GE-2 to Ge-1 to reach G0. If GX101 fails, traffic from A0 to G0 now requires 17 intermediate hops and correspondingly higher latency.

Meanwhile, traffic from G0 to IX1 that should go through the single intermediate hop of GX1-1 will have to go from G0 to E0 to B0 and then to IX1.

This additional traffic can overwhelm the connection and potentially cause higher latency and congestion-related packet loss. Peering through IX typically has much more capacity and capability to handle the higher volume of traffic. When a single intermediate hop, GX1-1, from G0 to IX1 is unavailable, the additional hops (TTL) and round-trip delay (RTT) through the alternate route can result in excessive or long hops, leading to packets being marked as undeliverable or timing out on Internet-based services.

The best connectivity between the two ISP networks via the IX and using backhaul is represented by the path H2 to H0 to HX1-1 to HX1-2 to IX1 to X1X2-1 to X1X2-2 to IX-2 to DX2-2 to DX2-1 to D0 to D2. Thus, there are 12 hops from POP to POP.

The next direct path should be via B0, a total of 16 hops. The path is H2 to H0 to HX1-1 to HX1-2 to IX1 to BX1-4 to BX1-3 to BX1-2 to BX1-1 to B0 to DB-4 to DB-3 to DB-2 to DB-1 to D0 to D2.

The next direct path would be via A0 via C0, a total of 19 hops. The path is H2 to H0 to HX1-1 to HX1-2 to IX1 to AX1-2 to AX1-1 to A0 to AC-1 to AC-2 to AC-3 to AC-4 to AC-5 to C0 to CD-1 to CD-2 to CD-3 to D0 to D2.

Due to routing policies and peer relationships, an indirect but possible path can be 30 hops, for example, via G9 via E0 via B0 via F0. The path is H2 to H0 to HX1-1 to HX1-2 to IX1 to GX1-1 to G0 to GE-1 to GE-2 to GE-3 to E0 to EB-1 to EB-2 to EB-3 to EB-4 to EB-5 to B0 to FB-5 to FB-4 to FB-3 to FB-2 to FB-1 to F0 to DF-5 to DF-4 to DF-3 to DF-2 to DF-1 to D0 to D2.

Loops occur when traffic cannot reach its destination due to poor or incorrect routing policies governing the intermediate devices between the origin and destination. For example, if traffic from C0 is intended to be routed to G0, C0 may choose to send traffic to B0, as it believes B0 will send traffic to E0, since C0 may believe that B0 and E0 are close to each other and this is the best path. However, B0 may not be directly peered with E0, but may have a strong peering relationship with F0. F0 also does not have a peering relationship or a path to E0, and therefore may send traffic to D0 instead. D0 only has two options: to send traffic to C0 or to B0, and in both cases, the end result is a looped, undeliverable traffic. This looping can also occur for other reasons, such as routing table failures, compromised devices, intrusions and other erroneous behavior, or other reasons.

The end result of too many hops and too high a latency is timeout or packet drop.

Figure 25 shows the strategic positioning of infrastructure to enhance performance. Within this example there are three or four key points where strategic positioning of SRV_AP servers and other GVN infrastructure will ensure optimal peering and performance between all points on the example network topology shown.

To include alternative routing options and failover, SRV_AP servers installed and operating at IX1-IDC, B5, and IX2-IDC, and possibly at D5, will provide peering with all other networks and provide stable paths between SRV_APs by providing the option to route around any damaged paths. This strategic positioning provides flexibility and the possibility to implement other performance enhancements.

Figure 26 illustrates how GVN can be combined with technologies such as Network Slingshot to achieve many advantages seamlessly across distances. Network Slingshot is further described in US Provisional Patent No. 62/266,060.

The first boundary is GVN EIP 26-322, between the internet and GVN. The next boundary is the security perimeter 26-182. This layered security approach protects the core infrastructure on which GVN is built.

A secure perimeter 26-182 between the GVN and the GVN backbone protects the high-speed global network. The portion of the GVN above the perimeter 26-822 has traffic flowing over the open Internet (OTT) via a secure GVN tunnel. Below the secure perimeter 26-182, GVN connections utilize various protocols over dark fiber or other connections not directly accessible from the Internet.

The supercomputer nodes 26-538 may operate inside (below) a secure perimeter 26-832 that may operate a true internal network with advanced features such as Remote Direct Memory Access (RDMA) to Parallel File System (PFS) 26-602 devices.

Figure 27 illustrates how the tables in various GVN device databases relate to each other and how they interact. For example, the repository database DB_2300 on SRV_CNTRL contains various tables related to devices and interactions between them via the GVN's Neutral API Mechanism (NAPIM). Tables in database DB_2300, such as the device registry DBT_2310, are designated as REPO_ACTIVE, meaning they receive information from many sources, read/write, and can be queried as information sources for selective or complete replication of tables, such as the device identification DBT_2102, as part of the EPD local database DB_2100. This table DBT_2101 has the flag SEL_REP+W, which allows for selective replication from DBT_2310 and for reporting relevant identification back to the device registry.

The control and release of information is managed by the data manager. Database table type indicators include "REGULAR" for normal read/write tables, REP_INFO for read-only replicas, SEL_REPSEL_REP for read-only partial replicas with only relevant rows, and REPOS_ACTIVE for merging all sources from a repository such as the device registry DBT_2310. Other possibilities include "LOGGING" for source tables to be merged from the database DB 2800 on SR V_LOG S. These table identifiers are for example purposes only and may differ in real-world applications, with more tables and other types existing depending on the application.

Figure 28 shows the collaborative efforts among various modules, mechanisms, technologies and other components of GVN.

GVNs exist in three layers. Layer 1 is the physical network layer on top of which the GVN is built (over-the-top (OTT)), such as the Internet. Layer 3 is the GVN network layer that client devices view as a partial or complete path to their destination. Layer 2 is the logical layer between these two layers.

There are components that interact with the physical conditions 28-00. The dynamic configuration module at 28-20 is dedicated to maintaining the connectivity of the GVN. The joint action described herein links the relevant modules of the GVN to the physical 28-00 and dynamic 28-20 elements. For example, in order for the Advanced Smart Path (ASR) module G106 to function properly, multiple access point servers (SRV_APs) GP106 must be placed in multiple locations with routing and peering GR106. In order for the EPD to select the most appropriate SRV_AP to establish a connection with, information about which SRV_AP is best is required. The ASR Server Availability Module SA106 ranks servers for that particular EPD based on information provided by the ASR Test Manager TM106, and when the EPD needs to establish a new tunnel, it uses the Server Availability List SA106 to establish the new tunnel. Subsequently, tests are run on the tunnel via TM106.

As another example, to operate NAPIM G102, an API listener and handler HL102 are required on the host server. Both the host client and the host server in NAPIM run an operations manager OM102 to handle the preparation, routing, handling, and processing of API requests and responses. The dynamic configuration of NAPIM requires a peer manager PM102, a related NAPIM action manager AM102, and transactions at the physical TP102 and dynamic TM102.

structure

The Advanced Smart Routing (ASR) feature of the GVN is shown. Specifically, the figure shows the Advanced Smart Routing (ASR) feature of the GVN within the End Point Device (EPD) 103 for multiple paths to egress points in multiple regions of the world.

Traffic in this example embodiment begins in LANA 102 from a connected device such as host client 101. The target traffic areas shown in this example embodiment are: 1) local traffic stays local via POP 401, where a GVN tunnel will not necessarily improve performance; 2) local traffic is carried in encrypted tunnel TUN1 to the Internet 203; 3) traffic destined for another area reaches SRV_AP 301 in that area via TUN2 to access the Internet 303; and 4) traffic reaches other remote areas via TUN3, where some ASR exists on SRV_AP 501.

DNS cache 103-4 within EPD 103 performs DNS lookups from DNS servers at each target zone, including DNS 404 for Internet 402, DNS 204 for Internet 203, DNS 304 for Internet 303, and DNS 504 for Internet 503. Internal DNS cache 103-4 is accessible via path DP4.

The physical network interface controller (NIC) hardware device of EPD 103 includes four ports. ETH0 103-9 is the WAN port that connects EPD 103 to the Internet's network access point (NAP) via P401, which leads to the ISP's POP 401, which leads to the Internet 402. All traffic from the EPD passes through this connection, which is the first layer of the GVN network. The TUN tunnel above this connection is the third layer of the GVN. ETH1 103-1 is a local area network (LAN) port connected to LAN A 102 via path P102. ETH2 103-2 is another physical LAN port connected to LAN B 104 via path P104. Finally, there is a virtual interface (VIF) acting as a bridge BR0 103-3, which is used to connect LAN interfaces 103-1 and 103-2 via internal paths DPI and DP2, respectively.

Traffic from LAN bridge BR0103-3 is sent to a chain of virtual interfaces (VIFs) via device path DP3. Advanced Smart Routing (ASR) is applied at each VIF, using the IP address routing table to direct traffic from each VIF to one of two or more egress points. The last VIF has only one possible egress point for all other remaining traffic.

For example, at VIF0 103-5, local traffic exits via P401. All other traffic passing through VIF0 103-5 is sent via DP5 to the next VIF in the chain, VIF1 103-6. Traffic from VIF1 103-6 destined for the Internet 203 exits EPD 103 via path P201, through encrypted tunnel TUN1 to SRV_AP 201, then to path P202 to POP 202 to P203 and then to the Internet 203. From this location, regional DNS lookups can be queried via SRV_DNS 204 via path P204. Connections to host client 205 or host server 206 are possible via P205 and P206, respectively.

Any remaining traffic from VIF1 103-6 is sent to VIF2 103-7 via path DP6. Based on the routing table applied to VIF2 103-7, all traffic destined for the Internet 303 and connected devices at that location, such as host server 306, leaves VIF2 via path P301 to TUN2 to SRV_AP 301 and continues through the Internet 303 and beyond.

Any remaining traffic from VIF2 103-7 is sent to VIF3 103-8. All traffic from VIF3 103-8 is sent via encrypted tunnel TUN3 to SRV_AP 501. ASR routing is applied at SRV_AP 501, so that traffic destined for IP addresses within Internet 503 is sent via path P502 to POP 502 and then to Internet 503.

Traffic from SRV_AP 501 destined for the Internet 603 is sent via the connected encrypted tunnel TUN4 to SRV_AP 601 to the path P602 to POP 602 to P603 to the Internet 603 and reaches somewhere else outside the Internet.

A DNS lookup in the area of the Internet 603 may be performed on SRV_DNS 604 and may connect to devices at that location, for example, via P 605 to a host server 605 or other device.

This ASR mechanism can be used at various traffic nodes to optimally send traffic to the best exit points on the Internet located in multiple target regions, thereby achieving geographical destination traffic and obtaining other advantages achieved by GVN.

Figure 30 shows a series of encrypted tunnels established between a client (C) and a server (S). Steps 30-0 to 30-18 show a series of simplified communications between C and S.

The first step is to open a connection 30-0 from C to S. The next step is S accepting the connection handshake 30-2. If the handshake data is malformed or does not match the expected format, the process can stop here.

After receiving and accepting the handshake 30-4, C provides the certificate to S so that S can use it along with the required security information to establish a Secure Sockets Layer (SSL) connection 30-8 between the two. The certificate received from C is compared with the corresponding certificate key on S. If the certificate is expired or incorrect, then the SSL connection cannot be established and the process stops.

This connection will be used to send information 30-10 about the tunnel from C to S, including a pass phrase, a metric, and other information about the tunnel metric, including which IP address and port each device will use for tunnel traffic, as well as other information.

S will verify this information against its own version of the tunnel metric and pass phrase and other information 30-12. If the information is not accurate, the process will stop at this step.

After successful authentication, S will send a response back to C so that C can begin the process of initiating or building a tunnel using the provided configuration settings 30-14.

After the tunnel is established, routes 30-16 can be applied at C, S, or both. Although the tunnel is established, traffic may not be able to flow through the tunnel during the process of adding routes to it. Even if traffic can flow through the tunnel, there is a risk of data leakage. This risk occurs because before all routes are applied, traffic destined for the destination IP address can leave the default egress path to the internet without encryption or passing through the tunnel. After the routes are added to the tunnel, subsequent traffic will be protected because it will be transmitted through the tunnel. Depending on the size of the routing table to be applied to the tunnel, this delay can be considerable.

When all routes have been applied to the tunnel, the tunnel can be used to push traffic through it 30-18.

Figure 31 illustrates the information flows required for two peers in a peer pair. The peers can be a client (C) and a server (S), or from one peer to another in a P-2-P topology. To simplify the notation and description in this example embodiment, C-to-S and P-2-P represent two peer relationships of the same type; the C-to-S relationship is described herein. GVN primarily uses C-to-S relationships between devices, but its methods and techniques can also be applied to P-2-P peer pairs for tunneling.

An encrypted tunnel is essentially a secure communication path through which data can flow. When the client and server are separated by a distance and the connection between them is over the open, unencrypted internet, an encrypted tunnel is ideal for securely exchanging data. If a human network administrator is present on either end, they can program the device. However, there are challenges in relaying secure information such as passphrases, keys, and other information. Some coordination can be done using voice calls, others using a series of posts to share information via a secure website, or other methods can be used. Setting up individual tunnels manually may be necessary. Managing multiple tunnels can become cumbersome.

In order to automatically build a series of encrypted tunnels between the two devices in a peer pair, information needs to be shared securely. The tunnel information also needs to be current and securely stored on the devices. Furthermore, during the setup process, there are threats that must be addressed. Even after the tunnel is established, there are still other threats that need to be addressed.

SRV_CNTRL 31D00 is a central server that includes a repository that manages information in database tables, files stored in a secure file storage system, lists located in storage, and other related information. SRV_CNTRL also has algorithms and mechanisms to evaluate certain data to generate information reports.

Client device 31D02 refers to a device that initiates tunnel establishment by "dialing" to a server device via a specific IP address and port. Many client devices 32D02 can simultaneously connect to the GVN using similar software and configuration. The distinguishing factors between devices are the unique device identifier (UUID) and unique information per client per channel.

A server device 31D06 represents a device that listens for client connection attempts at a specific IP address and port. If the client follows the correct protocol and setup sequence, and provides the correct credentials and other security information, the server will allow the client to establish a tunnel to the server. Many server 31D06 devices with similar software and configuration can simultaneously connect to the GVN, distinguished by their unique device identifier (UUID) and unique information.

Tunnel information 31S2 shows information stored on client device 31D02 and server device 31D06. Each device can establish multiple tunnels, and each tunnel will have its own set of tunnel information and security information. Some tunnel information sets can be used to build the currently active tunnel, and other tunnel information sets can be saved in a repository for use in future tunnels.

Some information between C and S is equivalent, such as the passphrase that one will present to the other, while other information will vary depending on availability. The information required to establish a tunnel between two points may include: client/server topology and settings; the IP and port of each endpoint that the tunnel will use; tunnel metrics, including MTU size, protocol, and other information used for its operation; keys, passphrases, and other information about the security protections used by the tunnel; SSL certificates and other information used to protect the information exchanged before the tunnel is established; and other information. This information is shared between devices using specific API action calls using the GVN neutral API.

Tunnel front 31S0 describes the process of receiving and sharing information between devices 31D02 31D06 and repository 31D00 on SRV_CNTRL, and returning it to devices 31D02 31D06. API communication paths API-31CP0, API-31CP2, API-31CP4, and API-31CP6 represent request-response information exchanges, with arrows indicating the direction of information flow from one device to another.

Server 31D06 reports this information to the Receive Information 31C-0 module of the SRV_CNTRL 31D00 device via API-31CP0. SRV_CNTRL 31D00 receives information from the server and stores relevant identifiers, tunnels, current load, and other information in its repository. For example, algorithms and AI logic on SRV_CNTRL 31D00 analyze server load and update the Server Availability C-1 matrix based on current and expected demand from the Client 31D02 device. Server Availability C-1 information can be transmitted via the Shared Information 31C-6 module replicating the database to the Client 31D02 via the GVN API via API call API-31CP6; via direct file sharing within the GVN; or other methods.

Client 31D02 reports this information to the Receive Information 31C-0 module of the SRV_CNTRL 31D00 device via API-31CP2. This information is stored in the repository of SRV_CNTRL 31D00. Tunnel-specific information from client 31D02 can be shared with server 31D04 via API-31CP4 using the Share Information 31C-6 module.

SRV_CNTRL 31D00 compiles a list of current clients 31C-4 per server, which is published to the server 31D06 via the shared information 31C-6 module via the path API-31CP4.

If either the client 31D02 or the server 31D06 detects a problem establishing the tunnel using the current tunnel information, one device or the other may request a new set of tunnel information to be generated by SRV_CNTRL via API-31CP2 or API-31CP0, respectively. The new set of tunnel information may be shared with both peers in the peer pair via shared information 31C-6, with the client 31D02 information being sent via API-31CP4 and the server D02 information being sent via API-31CP6.

The client 31C-4 list and the current status of the server 31D06 will directly affect the server availability 31C-2.

Each server 31D06 needs to organize, protect, and coordinate its list of clients 31C-4 that will attempt to establish new tunnels to the shared resources of the server 31D06. This information will be fluid and will need to be updated regularly via secure API calls to SRV_CNTRL 31D00.

The need to securely coordinate information between devices is necessary to protect the integrity of the tunnels between them.

The tunnel establishment phase 31S4 describes the process of establishing a tunnel via shared information 31C-6. Refer to Figure 30 for the steps taken to establish a tunnel between a client and a server. Path 31TP0 represents the path between client 31D02 and information exchange 31C-10, and from information exchange 31C-10 to server 31D06 via path 31TP2.

Establishment threats 31C-8 are threats to the information exchange 31C-10 during tunnel establishment. If a tunnel-type signature is visible, then threats 31CC-8 may exist during tunnel establishment, such as a fake Transport Layer Security (TLS) handshake from an intermediary illegal operator, TLS errors during the handshake, blocked or obstructed port and IP identification, timeouts caused by filtering devices, reset packets sent by intermediary ISPs or firewalls or devices, or other threats.

If the information exchange 31C-10 is successful, the step of building a tunnel 31C-12 is executed, in which routing and other related operations are applied to enable a tunnel TUN to be securely built between the client 31D02 and the server 31D06.

Tunnel establishment 31S6 describes the stages during normal traffic flow through a tunnel. Information must be communicated between devices, and SRV_CNTRL D00 is required to manage unique information for the various client 31D02 and server 31D06 devices, as well as the multiple tunnels established between them.

Information exchange between devices must occur regularly because it is often necessary to form new dynamic tunnels. Some ports on an IP address may be blocked or become blocked, and simply changing the port for that IP address will allow the tunnel to be built and data to flow. In addition, each tunnel requires one or more unique ports per IP address to avoid conflicts between tunnels. When a client 31D02 device requests the creation of new tunnel information, a random port number is generated and the port availability for that specific IP address on the target server 31D06 is checked based on two or more of the following factors: whether the port is already in use by an existing tunnel (an operational port or a standby port that can enter an operational state); and whether the port has been used in the past by a specific client 31D02/server 31D06 peer pair and whether it has been blocked. In both cases, a new random number will be generated. There are 65,536 available ports per IP address, with a certain number reserved for specific services. For example, a lower limit of 5,500 will leave 60,036 available ports, which can be used by a random number generator with a minimum value of 5001 and a maximum value of 65536. When a tunnel is torn down and a port is marked blocked for a peer pair, it becomes available for use by another peer pair. This port release is necessary to avoid port exhaustion. Therefore, it is necessary for SRV_CNTRL 31D00 to keep track of IP and port combinations.

Tunnels can be set up by themselves through procedures, but this has limitations. While secure, most tunnels are visible during their establishment. Handshakes and signatures regarding the tunnel type are visible during operation. Manually setting keys is tedious and infrequently changed, increasing the risk of them becoming compromised if used for extended periods; therefore, keys should be frequently replaced with new ones.

The automated system needs to ensure that information, such as new keys, IP addresses, ports, and other information, can be created and made available to both peers to enable tunnel establishment and reestablishment. Both peers must be configured and ready to establish the tunnel. Therefore, the information exchange between the peers needs to be secure, otherwise the security integrity of the tunnel itself will be compromised.

Although the tunnel has been established and is pushing traffic, there is an operational threat 31C-14. The tunnel signature may be visible (for example, if the tunnel is sniffable without being obfuscated). If the tunnel type can be discovered, then the tunnel structure is known. This creates the risk that the packet stream can be intercepted and the tunnel contents can be decrypted using a brute force key cracking. If the reset code or other tunnel control code is known, then the reset signal may interrupt the tunnel. Therefore, in order to maintain the security and integrity of the tunnel between the client 31D02 and server 31D06 devices in the peer pair, information needs to be updated and shared automatically and securely.

The GVN architecture enables devices to automatically and securely establish tunnels between peer pairs based on the latest information. The combination of security features and methods provides self-enforcing protection.

Figures 32-35 illustrate the third layer of neutrality and security of the GVN with respect to the GVN tunnel, while comparing the number of hops to the number of hops of the basic Internet connection. The use of the term LAN in these figures is general and can represent the network of a home or office or an Internet data center (IDC). The device can be a client or server connected to the LAN. Figure 32 shows a GVN tunnel from the LAN to the EPD to the SRV_AP to the Internet. Figure 33 shows a GVN tunnel from the LAN to the EPD to the SRV_AP to the EPD to the LAN. Figure 34 shows a GVN tunnel from the LAN to the EPD to the SRV_AP to the SRV_AP to the EPD to the LAN. Figure 35 shows additional elements of the GVN tunnel from the LAN to the EPD to the SRV_AP to the SRV_AP to the EPD to the LAN of Figure 34, which includes peers.

All four figures include a common baseline element from EH1 to EH17, which represents the external hops of the basic internet connection. The distances between each hop are not to scale and do not represent anything other than the number of hops. Other common elements include a local area network LAN1 with a gateway device GWD1 at one end and another LAN2 with GWD2 at the other end. Each variation of this example embodiment also has a GVN endpoint device EPD-1 connected to an access point server AP-1. Tunnels exist between these devices, and each device NH1 and NH2 within the third layer of the GVN has a neutral hop.

Figure 32 shows a GVN tunnel from the LAN to the EPD to the SRV_AP to the Internet. The tunnel can also function in the other direction, providing access from the Internet to the GVN tunnel and back to the LAN. There is a point of presence POP-1 between AP-1 and the Internet. There is another POP-2 between the Internet and GWD2, which represents the network access point (NAP) for the connection of the LAN.

Figure 33 shows a GVN tunnel from LAN to EPD to SRV_AP to EPD to LAN. This variation shows an end-to-end GVN tunnel between the edges of two LANs via a single SRV_AP. The difference between this variation and Figure 32 is that the tunnel extends through the entire transport from EH3 to EH15 via the Internet. A second EPD-2 is shown.

There is one tunnel between EPD-1 and AP-1. This connects to a second tunnel between AP-1 and EPD-2. Compared to the 13 hops on the underlying Internet between EH3 and EH15, there are three neutral hops within the third layer of the GVN, represented by NH1, NH2, and NH3.

Therefore, the total hop count from LAN1 to LAN2 is a minimum of seven hops from LAN1 to GWD1 to NH1 to NH2 to NH3 to GWD2 to LAN2. The end-to-end count includes two internal hops at both ends from EH1 to EH17 and totals a minimum of 17 hops.

FIG34 illustrates a GVN tunnel from LAN to EPD to SRV_AP to SRV_AP to EPD to LAN. This variation shows an end-to-end GVN tunnel between the edges of two LANs via two (or possibly more) SRV_APs. The difference between this variation and FIG33 is that a second AP-2 is inserted into the path to represent another connection, tunneling AP-1 to AP-2 and tunneling AP-2 to EPD-2. Adding another internal neutral hop brings the hop count within Layer 3 of the GVN to eight.

Figure 35 shows additional elements of the GVN tunnel from LAN to EPD to SRV_AP to SRV_AP to EPD to LAN of Figure 34, including peering points that peer between the ISP and the edge of the network. This variation shows an end-to-end GVN tunnel between the edges of the two LANs via two SRV_APs, and further shows more information about the different Internet Service Providers (ISPs) carrying traffic between EH-3 and EH-15 through certain parts of the Internet.

The difference between this variation and Figure 34 is that additional elements have been indicated. The following elements, as shown in Figure 9, have been covered in this variation of the example embodiment: a) EDGE-1 is the demarcation point for the network access connection between the devices of LAN-1 and the POP of ISP-1; b) PP-01 is the point at which peering occurs between the networks of ISP-1 and ISP-2; c) PP-02 is the point at which peering occurs between the networks of ISP-2 and ISP-3; and d) EDGE-2 is the demarcation point for the network access connection between the devices of LAN-2 and the POP of ISP-3.

Certain advantages can be achieved by placing SRV_AP-1 at PP-1 so that it can directly peer with both ISP-1 and ISP-2. Further advantages can be achieved by placing SRV_AP-2 at PP-2 so that it can directly peer with both ISP-2 and ISP-3. If ISP-2's network is less than ideal, traffic can alternatively be routed by the GVN through another route or line or ISP or carrier, bypassing ISP-2.

The hop count through the neutral third layer of the GVN remains at eight as in Figure 34. The distances between ISPs are not to scale. Furthermore, there may be more hops within the ISP's network, but the number shown has been simplified for simplicity.

While Figures 33, 34, and 35 all illustrate tunneling at the AP hop, this is considered a single tunnel for client devices within LAN1 and LAN2. This single tunnel represents the neutral Layer 3 of the GVN, within which all traffic typically transmitted over the Internet can run, including TCP, UDP, and other protocols, as well as other tunnels such as IPSec, OpenVPN, PPTP, and others. The Layer 3 of the GVN also enables other advantages. These include lower TTLs and the ability to have more control over routing, among others.

FIG35 illustrates weaving various network structures together into a network carpet framework. This example embodiment illustrates weaving various network structures together at the physical layer, with a global virtual network (GVN) operating over the physical layer (OTT). These structures at the physical layer 36102 form a series of network segments that can, for example, be IPv4 and IPv6 aware, or just one or the other protocol. The endpoint device (EPD) 36100 to the LAN (36000) can be IPv4 and/or IPv6. The tunnel TUN 36P2 can be one or the other protocol, or both protocols, between the EPD 36100 and the access point server (SRV_AP) 36300.

Exit/Entry Point (EIP) 36302 indicates the exit and entry points from the GVN to the network structure at the Internet level. Path 36P04 indicates a connection to the IPv4 Internet network 36400, and path 36P06 indicates a connection to the IPv6 Internet network 36600.

The key point is that the carpet framework of the GVN allows structures such as an end-to-end link from the IPv4 Internet 36408 to IPv4 in a LAN 3600 or end-to-end IPv6 3608 from the Internet 36600 to a LAN 36000 even though there may be some different segments at the physical layer 36102.

Figure 37 shows a communication path for automated device collaboration in a GVN. This example embodiment shows a communication path used by Neutral API Mechanism (NAPIM) APIs 37202 37206 37208 to implement automated interactions between various devices working together to form a global virtual network (GVN), such as P37202-C.

Key operational aspects can be automated to facilitate rapid system response. These include infrastructure operations, heartbeat routines, connectivity, testing and diagnostics, and other functions.

Infrastructure operations such as predictably updating device operating system software and packages from reliable sources, maintaining GVN modules and databases, and other operations. For example, the endpoint device (EPD) 100 can query the central control server (SRV_CNTRL) 200 via API 37202 along path P37202-B to 37202-C. In another example, the email portal server (SRV_GW_Email) 37310 can update system packages from SRV_CNTRL 200, which is a reliable source of trusted system software.

Other items such as heartbeat functions, which operate via daemons or other recurring operations, include keeping services up, running, and healthy by reporting from a device (such as access point server (SRV_AP) 300) via API 37202 via paths P37202-A to P37202-C to SRV_CNTRL 200. Redundant paths also exist, such as via API 37208 via paths P37208-A to P37208-C. Other heartbeat functions can keep queues running and clear them, replicate logging data, and perform other such operations.

For a connection (such as tunnel P37206-C between EPD 100 and SRV_AP 300), both ends of the tunnel, the listener at SRV_AP 300 and the initiator EPD 100, require relevant information. This information may include peer pair information related to each device or related to the tunnel. Both communicate with SRV_CNTRL 200 via independent paths via API 37202.

With multiple tunnels attached to a virtual interface and the option of more than one tunnel between devices (such as between EPD 100 to SRV_AP 200 or SRV_AP 200 to SRV_AP 20x), various different API calls are required to manage the multiple tunnels, routes, and other information.

The Power Server Availability Algorithm relies on systematic analysis of various information to provide EPDs with a list of SRV_AP servers they can connect to via tunnels. Since each tunnel requires an IP address and port at either end of the GVN fabric for routing clarity, this information needs to be updated as it changes. Automated device collaboration helps with this.

A key component for information sharing is the sharing of test and diagnostic data from the physical network at layer 1, from the GVN fabric layer 3, and from the logic at GVN layer 2. This connection information provides more information about the analysis of the SRV_CNTRL 200. A copy of this data can also be sent to the logging server via API 37208 or other communication paths. The analysis results can also be stored on the logging server.

The API can also be used to update information about each peer in the pairing itself (such as peer pair credentials, ID, and other information), queues on each peer, transaction logs used for mediation, be updated through internal security audits, and be used to update or add or deprecate action functions of the API mechanism itself.

System and resource monitoring and reporting are also critical for automatically communicating information about services that are up and running, hosts that are functioning, database engines that are up and running, security systems that are functioning, and more.

Figure 38 illustrates the issues and challenges of dynamic tunnel establishment. This example uses the transfer of files, database structures, and other data from a repository 38R-00 in the GVN to a device 38D-00 to illustrate the issues and challenges of dynamic tunnel establishment. In most cases, the repository 38R-00 will be on a central server (SRV_CNTRL) in the GVN. The device 38D-00 can be an endpoint device (EPD), an access point server (SRV_AP), a gateway server (SRV_GW_XX), or other GVN device.

Depending on the device type, a newly created device can load a copy of the master disk to be configured during the first boot, or, as in the case of a remote server, a first boot script will be securely transferred to the server to be run to pull the basic system files. Other possible scenarios may combine a combination of pre-loaded files and files to be loaded remotely.

When the first boot script is run, most of the current database structure is copied from the repository 38R-00 from the DB structure repository 38R-06-A to the Db 38D-04 on the device 38D-00. The data that populates the database is sent from the DB data repository 38R-06-B to the identification information module 38S-00 via 38P06. Some of the data passed through 38S-00 may be filtered and modified to incorporate identification information (such as Device_ID and other UUID elements), and other data is passed through directly without modification.

Data applicable to device 38D-00 is sent to database 38D-04 via path 38P16 based on the device type and its universally unique identifier (UUID). Some information may also be populated into a template configuration file, which can be cloned into software and configuration file storage 38D-02 on device 38D-00. Identifying information unique to a device may include device attributes, naming and UUID information, credentials/keys, key modifiers, and other information.

Configuration files for system packages and other modules are cloned from configuration file repository 38R-02-B on repository 38R-00 and sent to software and configuration file storage 38D-02 on device 38D-00 via path 38P02. Some "factory default settings" and other files may also be copied to secure file storage 38D06 on device 38D-0 via path 38P10. Secure file storage 38D-06 is managed by the GVN's file and folder manager. Files from 38D-06 may also be cloned to 38D-02 via 38P12 when needed, such as in the event of a necessary return to factory settings.

The code base file 39R-02-A from the repository 39R-00 may be copied to the software and configuration file storage 38D-02 via path 38P00 and may also be copied to the secure file storage 38D-06 via path 38P8.

The above illustrates the loading of files and data from the repository to the device during first boot, updates, periodic data exchanges, and other operations.

Figure 39 shows bridging two LANs into a wide area network (WAN) via two or more EPDs. More specifically, this figure shows bridging two LANs 39-000 and 39-010 into a wide area network (WAN) via EPDs. Each EPD first connects to an access point server SRV_AP 39-200 via a base station tunnel established over its Internet connection.

From EPD 39-100, the base station connectivity path OTT is via path 39-PO02 to point of presence (POP) 39-002 to the Internet 39-004 to POP 39-006 of SRV_AP 39-200. From EPD 39-110, the base station connectivity path OTT is via path 39-PO12 to point of presence (POP) 39-012 to the Internet 39-014 to POP 39-016 of SRV_AP 39-200.

The transmission path 39-P06 from POP 39-006 to POP 39-016 may be a path through the Internet, by passing through the SRV_AP and relying on routing on the public network. If EPD 39-100 wants to connect to 39-102 via the Internet, it may follow a different route based on policies that are beyond the control of the GVN or EPD.

EPD 39-100 establishes a tunnel, TUN 39-P10, between itself and SRV_AP 39-200. EPD 39-102 also establishes a tunnel, TUN 39-P12, between itself and SRV_AP 39-200. One or both of these tunnels may or may not be encrypted or protected. There may also be another tunnel, an internal tunnel, INT TUN 39-P20, that passes through the two other tunnels and joins at SRV_AP 39-200, through which traffic can flow. This tunnel may establish a WAN communication path.

The tunnel and base station connection connectivity can use different network protocols. The network carpet framework provided by the GVN can be a mixture of different network protocols mapped to a series of various network segments, while the GVN can be one type of network end to end within the internal tunnel.

Figure 40 illustrates a multi-perimeter firewall mechanism (MPFWM) running on a GVN. This example illustrates how a second level 40TOP88 can exist above the elements (OTT) in a global virtual network (GVN). At the first level OTT 40TOP86, the GVN 40-86 operates the OTT, the base station Internet connectivity 40-82. In the case of a multi-perimeter firewall mechanism 40-88 configuration, the GVN operates the OTT and can thus be configured as a second level 40TOP88 above the top element.

FIG41 illustrates a GVN stack built on top of the Internet (OTT). This example depicts a GVN 41-800 stack built on top of the Internet 41-000. The figure illustrates connectivity between an EPD 100 and two SRV_AP servers 300 and 302 via tunnels TUN 41-100-300 and TUN 41-100-302. These two tunnels are examples of multiple tunnel options between an EPD and a best-current access point server (SRV_AP), based on server availability and other factors such as destination, traffic type, QoS of various network segments between the origin and destination, and others.

The carpet framework 41 - 500 weaves together the various network protocols of the independent network segments as well as the end-to-end protocols that may be “through” the GVN path.

Clustered GVN devices 41-600 represent the physical layer of routing between GVN devices.

The GVN Global Network OTT Internet+ via other links 41-700 is the GVN layer 2 logic, where modules such as geographic destination, DNS management, Advanced Smart Routing (ASR)/Global ASR (GASR), server availability, tunnel management and builder modules, etc. operate.

GVN 41-800 represents the network seen by client users.

FIG42 compares the Internet Protocol IP stack B2, the OSI model C2, and the GVN stack C3.

The IP stack consists of the network interface T1, the internet T2, transport T3, and applications T4.

For non-GVN traffic and for the client-invisible physical tunnel flowing through ETH NIC N1, the IP stack seen by the client is along element R1 at the network interface T1 layer, element R2A at the internet T2 layer, element R3A or R3B at the transport T3 layer, and element R4A, R4B or R4C at the application T4 layer.

For traffic passing through the GVN tunnel and network, the client will observe its GVN traffic at R4C at the network interface T1 layer, R5 at the internet T2 layer, R6A or R6B at the transport T3 layer, and R7A, R7B, or R7C at the application T4 layer.

While the OSI model may be used by the client for IP traffic passing through the tunnel, the GVN has its own stack of network interfaces G1, internet G2, transport G3, GVN routing and logic G4, GVN internet G5, GVN transport G6, and applications G7.

logic

Shown is the global Internet flow between countries via numerous possible routes. Traffic on the global Internet flows between countries via numerous possible routes that carry different interconnections between peers.

Internet access in regions such as Asia is primarily connected to one another by terrestrial and submerged ocean links, often linking to a third country or other country in the middle of traffic transmission from one country to another.

43-X01 represents the most direct route from Asia to Europe. For example, the latency from Hong Kong to Paris via 43-X01 will be between 180ms and 250ms depending on the route taken.

43-X02 is an indirect, longer path where traffic is naturally pushed through the internet. Here, traffic goes from Asia via link 43-P400 to the US West Coast 43-400, then via link 43P402 to the US East Coast 43-402, and then via link 43P600 to the landing point in Europe 43-600. The latency via 43-X02 will be approximately 396ms to 550ms or more, depending on the destination in Europe.

Before leaving the region, traffic may have to be relayed from one country to one or more other countries (etc.) before it can access the international backbone. Such additional intra-regional hops can add 50ms to 150ms or more to the RTT, even before the traffic leaves the region.

Once in the destination region, traffic will land in a country, such as the UK 43-600, from transatlantic link 43P600. From the UK 43-600, traffic will run via link 43-600 to France 43-602 and then via link 43P606 to Germany 43-606. This additional intra-region hop can add 30ms to more milliseconds to the RTT, depending on the destination.

International backhaul quality can also vary between peers, each with varying RTT QoS times. Routing and corresponding speeds are intermediary players in the regular internet, and in most cases, these are based on the lowest cost, typically delivering slow RTT speeds. High latency isn't the only issue lower-quality networks have to contend with. These often have higher congestion levels and correspondingly higher packet loss. Lossy and slow links significantly degrade performance.

Figure 44 again compares the Internet Protocol (IP) stack, the OSI model, and the GVN network stack. This example again compares various conceptual network models such as the TCP/IP stack B2, the Open Systems Interconnection (OSI) model A2C2, and variations such as the TCP/IP model in the GVN stack A3, and the GVN C3 model.

Two perspectives are presented. Client perspective A1 compares A2 and A3 side by side. Global virtual model architecture C1 compares C2 and C3. There is also a tree-like connection layer B2.

In the TCP/IP model B2, there is a network interface T1 corresponding to the Ethernet protocol R1. The Internet T2 corresponds to the Internet Protocol (IP) R2. The transport layer T3 corresponds to the TCP protocol R3A and the UDP protocol R3B. Other protocols may exist and operate at this layer. Above this layer is the application layer T4, which includes the Hypertext Transfer Protocol HTTP R4A, the mail service POP3 R4B, and the GVN application. Other applications such as the File Transfer Protocol (FTP) or other services may also exist at this layer.

To compare the TCP/IP model with the OSI model in scope B2, the OSI data link S9 and physical link S8 are parallel to T1. The OSI network S10 is parallel to T2. The OSI transport S11 is parallel to T3.

The OSI session S12, presentation S13 and application S14 layers are within the scope of R4C, GVN application.

The extension of the network tree to the top of R4C is established through the TCP/IP model of GVN B3.

From the client's perspective, layers T1, T2, T3, and T4 are combined into a single TCP/IP model layer, T5, which becomes the network interface layer for the GVN, a neutral third layer. This is comparable to the OSI model A2 physical S1 and data link S2 layers.

Above R4C, there is a representation of the Internet layer in layer 3. The Internet IP layer is at R5 and this corresponds to the A3 level of the Internet T6 and the A2 network level S3.

TCP protocol R6A and UDP protocol R6B correspond to this level with A3 level transmission T7 and A2 level transmission S4. Other protocols may exist and operate at this layer.

From the client's perspective, the application layer T8 corresponds to Internet protocols such as FTP R7A, HTTP R7B, and POP3. The OSI model divides the application layer T8 into three layers: session S5, presentation S6, and application S7.

In the three-layer model of GVN, A1 describes operations in layer 3 while B1, B2 describe operations in layer 1. The GVN application R4C at T4 and operations under C1 describe how the second layer is used to allow the third layer to operate on top of the first layer.

There are similarities between the network operations in the third layer and the first layer of GVN.

The network connectivity NO may be other network connectivity on the regular Internet N1 to the Internet via a WAN N2, a dedicated circuit N3, an MPLS line N4 or other link.

Figure 45 illustrates a tunnel between two LANs via the GVN. Specifically, this figure depicts the internal path from LAN 45-000 to LAN 45-002 via GVN paths 45P00 to 45P10, which are segmented through internal tunnel 45L300. In either direction between the two LANs, there are five hops 45H0 to 45H8 visible to the client. The path through 45L300 is the GVN layer visible to the client.

The GVN Level 1 network layer 45L100 represents the physical network layer end-to-end for various types of network segments. Although the number of hops is not indicated in this figure, the network segments are at least equal to and most likely larger than those visible to the client in the internal tunnel 45L300.

Logical layer level 2 logic 45L200 is the logic where various network segment integration, routing, and other GVN operations occur.

If the client path is IPv6 through a tunnel, just like 45-104 for the IPv4 segment, the internal IPv6 traffic can be packetized in such a way that it can remain native IPv6 end-to-end regardless of the network type of the network layer 45L100.

FIG. 46 compares the network at base station level via paths P01 to P13 with the network through GVNs T01 to T03.

At the base station internet-level CTN 140, extensive measurements are made from the LAN to the GVN via EPD 46-100 to SRV_AP 46-300. Connectivity metrics such as bandwidth (BW), latency (Δt = A ms), packet loss, and other factors are evaluated for these measurements. At the other end of the connection, similar measurements of BW, Δt = C ms, packet loss, and other factors at CTN 142 measure the rise in traffic from EPD 46-102 to the GVN. Through the GVN between SRV_AP 46-300 and SRV_AP 46-302, various internet segments (CTN 340) measure BW, Δt = B ms, packet loss, and other factors for GVN cross-regional OTT. The total path latency through GVN layer 3, GVN 4-3, can be calculated as the sum of latency times A+B+C, all measured in milliseconds.

At GVN layer 3, GVN4-3, ASR and other features govern how and where traffic flows through the GVN. This requires determining the best tunnel and traffic type to send traffic based on the target area, the QoS of the segments passing through the GVN, and other factors.

At the GVN layer, GVN4-1, the physical conditions of the base station's network connectivity are monitored and tested to determine the best routing options. GVN tunnels and paths through them are then constructed based on these routing options. GVN paths can be transported through connected tunnels that pass through SRV_APs, SRV_BBXs, and other GVN hardware devices. This also determines which tunnels to continue using and which to abandon.

The mechanisms, modules and components at GVN layer two GVN 4-2 facilitate setting up, testing, managing and otherwise operating the pipe between layer three GVN 4-3 and GVN layer one GVN 4-1. Tunnel testing 46-310 may be accomplished at layer three at the EPD 4100 and at the SRV_AP 46-300 via its tunnel tester 46-312.

Figure 47 shows the Advanced Smart Routing (ASR) feature and elements of the geographic destination mechanism of the GVN within the endpoint device (EPD). This includes using multiple DNS sources to send traffic via multiple paths to egress points in various regions of the world. The target traffic areas shown in this example embodiment are: 1) local traffic remains local from VIF3 47-118 to the Internet 47-004; 2) traffic destined for the other regional Internet 47-002 will be from VIF1 47-112 through TUN1 102-6 to path 47P48 to SRV_AP 47-300 and then to the Internet 47-002 via path 47P50; 3) traffic for the other regional Internet 47-006 will be from VIF2 47-116 through TUN2 102-8 to path 47P52 to SRV_AP 47-302 and then to the Internet 47-006 via path 47P54; and 4) traffic for the other regional Internet 47-008 will be from VIF3 47-118 through TUN3 102-10 to path 47P56 to SRV_AP 47-304 and then via path 47P62 to the Internet 47-008.

The SRV_AP 47-304 includes more detail to illustrate some of the functionality of its components, the AP logic 47-314 and the content pull proxy 47-318. Additionally, the EPD 100 includes a flow diagram in more detail to illustrate its internal functional components.

Tunnels TUN1 102-6, TUN2 102-8, TUN3 102-10 and traffic flows through the VJF with routing tables applied at each of virtual interfaces VIF1 47-112, VIF2 47-116, VIF3 47-118 operate in a similar manner to virtual interfaces and tunnels.

The DNS cache 47-114 is seeded from multiple DNS sources via a local DNS query mechanism 47-110 through path 47P38 via 47P34 to the Internet 47-004 to SRV_DNS 47-104. The remote DNS query mechanism 47-108 may make DNS requests via a content pull proxy (CPA) 47-318 via 47P44 to SRV_DNS 47-114.

The geographic destination mechanism (Geo-D) pushes routing information to the routing manager 47-104 via 47P04, which connects the content delivery agent (CDA) 47-106 with the CPA 47-318. Paths 47P30 to 47P40 via J01 are abstractions representing the coordination of the CPA 47-318 and the CDA 47-106 working together. Communication between the CPA and CDA is still via tunnels and/or API calls, or via linked cache transfers, through tunnels, or other mechanisms.

In this example embodiment, through Geo-D, the CPA 47-318 pulls all regional content from the Internet 47-008 via 47P62 to the SRV_AP 47-304 to pull the content from the host server 47-110 hosting the destination content via 47P66. Within the content, the CPA 47-318 may find links to other content and the CPA 47-318 will then pull the content stream from the host server 47-108 via 47P64. Other content may be pulled from the host server 47-112 via 47P68. Typically, many websites host web pages on one server, stream video files from another server, and provide graphics from another server.

Figure 48 shows an example of multiple parallel traffic paths taken through a GVN. The left side of EDGE-1 represents the LAN side. The right side represents the Internet-facing side. The right side of EDGE-2 represents the LAN side and the left side represents the Internet-facing side.

Traffic from devices in LAN 001 leaves EPD 101 via P002 through encrypted tunnel P003 to SRV_AP 102 and can flow out to the public Internet 106 to reach host client or server device D005 via path H005. Traffic from devices in LAN 201 leaves EPD 301 via P103 to SRV_AP 302 and can flow out to the Internet 106 via P106 to reach host client or server device D005 via path H005.

EPD 101 can be linked to EPD 301 via Internet 106 via P003 to SRV_AP 102 to P006 to Internet 106 to P106 to SRV_AP 302 to P103 to EPD 301. A secure tunnel exists between the EPD and SRV_AP via paths P003 and P103. To ensure full security, the path between EPDs for an end-to-end secure tunnel is EPD 101 to P005 to SRV_AP 103 to P007 to WAN 107 to P107 to SRV_AP 302 to P105 to EPD 301.

EPD 101 may build a secure tunnel via P003 to SRV_AP 102 and from there link to another secure tunnel via P201 to WAN 103 to P202 to SRV_AP 104 and then outbound in the remote region via path P203 to Internet 105 and via path H002 to host client or server device D002.

EPD 301 may build a secure tunnel via P103 to SRV_AP 302 and from there link to another secure tunnel via P301 to WAN303 to P302 to SRV_AP 304 and then outbound in the remote region via path P303 to Internet 305 and via path H004 to host client or server device D004.

EPD 101 can also reach devices in Internet 305 via secure tunnels between EPD 101 to SRV_102 to SRV_AP 302 to SRV_AP 304 and out to Internet 305 from there.

EPD 301 can also reach devices in Internet 105 via secure tunnels between EPD 301 to SRV_302 to SRV_AP 102 to SRV_AP 104 and flow out from there to Internet 105 .

There are numerous other options via end-to-end tunnel routing, tunneling to an egress point on the open Internet, tunneling via multiple SRV_AP devices, and other options.

The important point illustrated by this example is that client traffic carried by the GVN is through the GVN layer 3, which from the client's perspective is the same path as through the Internet and is therefore capable of carrying any type of traffic that passes through it, while still recognizing the improved benefits and higher security provided by the GVN.

For example, path P008 shows WAN optimized connectivity between firewall GW 002 and firewall GW 202 to create a LAN-WAN-LAN bridge. Device-to-device communications are carried within the third layer of the GVN and are transparent to GW 002 and GW 202.

For simplicity, point of presence (POP) network access points are not shown in this figure. The path to device D002 to and from the Internet, such as Internet 105, has a POP in the middle of H002.

The WAN in this example embodiment represents a secure tunnel between GVN devices over the Internet, and therefore any reference to the WAN is at layer 3 of the GVN, with all GVN traffic still traveling layer 1.

Figure 49 depicts Automatic Advanced Intelligent Routing (ASR) from a starting device 49-000 to an endpoint device 49-800. If a route is unavailable, Automatic Advanced Intelligent Routing can build a route, including but not limited to building a new tunnel and updating internal routing for the most optimized path.

Tables 1 through 5 are used by the algorithm as data points for routing purposes, such as determining the best egress point for traffic from the GVN through the access point server to the open internet. This data can also be used by the algorithm to help prioritize which route over another.

Table 1 lists the various available paths from the origin to the destination and includes a ranking of the paths.

Table #1 - Evaluating QoS of various routes through GVN

The EPD and SRV_AP2 indicate the egress/entry point (EIP) from the device to the internet or vice versa. The bidirectional arrow symbolizes the routing path between the two devices. This can be a network segment above the internet, directly through the internet via a tunnel or other mechanism (possibly as part of a GVN), or via another network path between the devices. The origin is on the left, and the destination indicates the final location to or from which the traffic will be routed.

The rating is a calculated value for a route based on several factors. A rating of 0.00 means an impossible route. A rating of 1.00 means the best route with the highest bandwidth at wireline speed and latency. RT_ID is a route ID number that distinguishes one route from another for practical purposes, testing, and logging purposes. This is used to determine the quality of various routes through the GVN. RT_ID is an identifier for a specific route from the route list.

Table 2 describes the server availability matrix.

Table #2 - Server Availability Matrix

The information maintained in the server availability matrix includes server_ID, server IP_address_ID, port number, EPD_ID field, parameter fields (including security and configuration settings, status flags, and timestamps).

The PRI is a weighted priority order for servers to connect to the EPD. Priority 1 is the absolute lowest priority. 0 indicates that the server is currently unreachable. This differs from the Flag_State, which indicates whether the record is current. The PRI can be maintained in the same table or in another related table, as the PRI is a continuously changing value and another table will allow for historical recording and analysis.

A Flag_State of 0 indicates that it is a spare entry. A Flag_State of 1 indicates that it is active and can be used. A Flag_State of -1 indicates that it has been retired and cannot be used.

Table 3 shows the delay times of the complete path and the delay times of the constituent network segments.

Table #3 - Routing->Path Delay Time Evaluation

The path from the LAN via the EPD to the GVN and either the Internet or a combination of various network segments has an overall path latency, otherwise known as RTT, round trip time. This time is measured in milliseconds (ms) and is used for an ICMP pulse from the origin to the destination and back to the origin.

To evaluate the best route, it can be broken down into groups of network segments that make up the overall network path. Evaluating each segment can provide information about the route and provide useful data points. Path ranking will always give extra priority to traffic that carries GVN OTT traffic over the open internet.

The total path delay time is the sum of the following delay times: LAN to EPD plus EPD to SRV_AP plus GVN transmission plus GVN outflow to the destination.

Table 4 lists the measured quality of service attributes of the routes.

Table #4 - Routing->Measured QoS Factors (Current and Historical)

This table is saved as a log record of current and historical QoS (Quality of Service) results for routes between a source peer and another peer in another location and/or region. It can be used in real time to make QoS expectation decisions based on current conditions. This table is located at each originating point device and indicates route performance.

Various factors are used to evaluate and compare line quality. These factors include system load (load), security (SEC), round-trip time (RTT), packet loss (R - reliability), bandwidth (BW), hop count (EFF - efficiency), and other factors (an array of values that can be used to evaluate line parameters).

Baselines are used for various points and network segments in between so that comparisons can be made between resources with different hardware configurations and network speeds, bandwidth, and other ratings.

L_ID indicates a row ID for recorded routing information.

RT_ID is a path id. The path may indicate a path through the base station Internet, through a tunnel, through a bonded tunnel, or other GVN-related routing.

Reg_ID is the target region ID.

RTT is the round trip time or latency based on historical standards. A value of 1.0 is standard, while values greater than 1.0 indicate lower than typical latency and values less than 1.0 indicate higher than typical latency.

SEC stands for Security Rating. A value of 1.0 is secure, while a value of 0.0 indicates a completely unsafe and compromised resource. This is based on security testing, performance records, and other data points. Any value below 1.0 is of concern.

R is reliability and relates to packet loss along a route. For example, R = 0.97 indicates 3% packet loss along a route. A value of R = 1.0 indicates 0% packet loss and 100% reliability. A rating greater than one indicates parallel replication of packets sent along the route. R = 2.0 indicates 100% reliability for the replicated packets sent.

EFF indicates the line efficiency in terms of hop count relative to the route length and is based on its historical average. An EFF value of 1.0 means a standard hop count and less than 1 means a larger than usual hop count. A value greater than one means a smaller than usual hop count.

BW (Bandwidth) is based on the route rating for a base station connection combined with a complete network segment between two points. A value of 1.0 for BW means 100% of BW is available. A value of 0.5 means only 50% of BW is available based on the route BW rating. And if the value is greater than one, such as 2.0, this means 200% of the route's BW capacity rating is available and can be used. For example, for a 1GigE base station link between two points, a rating of 0.55 indicates 550 Mbps is available. A rating of 2.0 indicates 2GigE can be used, and so on.

In the case of RT_ID=1, a SEC (Security) value of 1.0 indicates that it is 100% secure, and values greater than one, RTT=1.1 and BW=2.0, indicate that the connectivity of the route RT_ID from one point to another has a 10% lower latency and twice the bandwidth of a comparable baseline performance of the average route between the points.

For example, where RT_ID=5, a security rating of 0.80 indicates that there is an ongoing security risk, and the associated available BW rating of 0.30 shows that the server is under attack such as DDoS or Brute Force, with multiple security threats such as onslaughts of multiple parallel requests that saturate the available BW (bandwidth) while degrading SEC (security).

Flag_State=1 indicates the current active route. And Flag_State=0 indicates the historical routing capability that is no longer used. Timestamp indicates the start time of the UNIX timestamp (the number of seconds since the time).

L_ID=3 and L_ID=5 show a comparison between the starting point and the region Reg_ID=44 at two different UNIX timestamps 1448674238 and 1448848558. This shows that the subsequent performance has improved from the previous rating. Compared to load=0.7, load=0.9 is better, and the basic network connectivity has also improved.

This table can also be used to determine the better of two routes from the originating device to the target region by comparing the QoS factors of each route. For example, L_ID=5 and L_ID=6 both indicate the current (Flag_State=1) route from the originating device to Reg_ID=44, even though the routes for RT_ID=5 and RT_ID=9 are different. The better of the two routes across this range is RT_ID=9 and should be weighted with a higher priority in the server availability list.

Table 5 evaluates and ranks the entry and exit points (EIPs) in the target region.

Table #5 - EIPs in Regions

The ATR field is an attribute field. This is an array of attributes used to describe the EIP specifications (RAM, cores, storage, other factors, etc.). The S_ID field stores the server ID. The IP_ID field stores the IP address ID. Bandwidth (BW) is measured in GigE. For example, 20 Mbps is 0.02, 100 Mbps is 0.1, 1 GigE is 1, and 40 GigE is 40.

QoS (Quality of Service) indicates the suitability of the server's current EIP (Entry/Exit Point) to handle connections and traffic. A QoS of 1.0 indicates an ideal state for a server connected to an EPD with acceptable available BW (bandwidth) and little to no load (a combination of the server's resource load, RAM, CPU, NIC, and other factors).

A QoS of less than 1.0 means that the server is being used. If the QoS is close to zero, this means that it is close to being completely useless due to capacity saturation. As a baseline and for system health, a QoS of less than 0.40 will indicate that the server will be prioritized with a lower rating, so that servers with healthier QoS are weighted to appear higher on the list and thus attract connections without overloading any current servers.

This assessment and rating mechanism can also be used as a determining factor as to how to support the construction of physical infrastructure.

FIG. 50 illustrates a security perimeter 50 - 182 between the BB/backbone layer below the perimeter 50 - 832 and the IP/Internet layer above the perimeter 50 - 822 .

Two layers of natural protection are in place. The first layer is that the only way to connect the two layers is via paths 50-TR6B22 and 50-TR6B32, which must traverse the security perimeter. Only valid GVN traffic can be transmitted in either direction, subject to both logical checks. Another layer of security protection is that the network types above and below the security perimeter 50-182 are different.

Figure 51 is a flow chart of Advanced Smart Routing (ASR) within a Global Virtual Network (GVN).

Starting from a host client 101 device in a local area network (LAN) 102 connected to an endpoint device (EPD) 103, the GVN provides numerous connection paths from the EPD to multiple potential endpoints. This flowchart is a high-level illustration of the routing logic, with packets being transported through the GVN using ASR for optimized performance. From the perspective of the host client 101, their traffic will flow through the Internet Protocol (IP) network, thanks to the very few hops and best possible latency of the GVN's Layer 3. The first layer of the GVN is an automatically configured network of base stations with the construction of virtual interfaces, tunnels, routing, and other network policies. The second layer of the GVN is the layer where the algorithms, software, and logic govern operations between Layer 3 and Layer 1.

The first major routing decision is at logic gate 104 within the EPOD, where traffic flows out to the local Internet 107 (where the EPD is located via path P104) or, if it will go through a securely wrapped and obfuscated tunnel via P107 to an access point server (SRV_AP) 110, providing optimal connectivity to the area where SRV_AP 110 is located. Before traffic flows out of SRV_AP 110, it passes through routing logic gate 111. Local traffic flowing out to the Internet 113 will go to host clients 115 or host servers 116 there via path P111. If the traffic is not local and is being relayed to another area, it will go to the next SRV_AP 119 via path P116 through tunnel 118.

At SRV_AP 119, three of the many possible routing options are shown by the paths that traffic can take. Logic gate 126 determines whether the traffic should remain and flow out to the local internet 129, or whether the traffic should be tunneled via P126 to an SRV_AP in another region 127. Another possibility is shown via path P119, which indicates a tunnel from SRV_AP 119 to another EPD 121 in a remote region. This is EPD 103 to EPD 121, bridged via multiple bridge tunnels.

A further possibility is that the traffic arrives at client device 125126 in LAN 122, where EPD 121 is located via EPD's connection P121.

Figure 52 is a flow diagram of the various routes available through the GVN from origin C 52-002 to destination S 52-502. There may be many more possible combinations that are not shown or discussed.

The path 52CP00 from client C 52-002 to EPD 52-108 can be used to measure the performance of clients traveling through the LAN to the EPD. The best route is determined after testing and evaluating real-time data on available paths. The GVN from the EPD enters the access point servers (SRV_AP) 52-102, 52-104, 52-106, 52-202, and 52-204 via the first hop 52CP00.

The path from the EPD to the first SRV_AP can be defined as and measured from the entry point from the EPD to the GVN. Internal hops from SRV_AP to SRV_AP follow internal routes that always attempt to maintain optimal path connectivity. These can be over-the-top internet, on a backbone, on dark fiber, or other relevant routes.

The best exit point outside the GVN also keeps local track, both in that remote area and also as a whole for the complete network segment from the origin to the destination.

Tests can be run on individual segments, combinations of segments, and the overall network path from one end to the other, taking into account various factors to be evaluated. Traffic type and path determination can be based on data attributes and profile QsS requirements. Primary path selection is always based on the best factor for the traffic on that path. This mechanism functions to match paths between destinations and origins for the best possible bidirectional routing of flows.

Table 6 is a list of IP addresses to be stored locally based on IP address, protocol (etc.) and port (etc.).

Table #6 - IP addresses to be saved locally

This table stores which IP addresses are to be stored locally so that the EIP (egress/entry point) is transmitted directly on the EPD or via an SRV_AP in the same region as the EPD.

The LRI_ID field holds the local routing IP address ID. A region value of 0 indicates that the IP address (etc.) to be stored locally should be directed to the internet from its local EIP from the EPD. Region values 1 to 300 indicate countries and regions. Higher region values indicate finer granularity. The IP4_Address field holds the IPv4 address.

Under fields such as protocol or port, an asterisk ("*") is a wildcard character that covers all possible values in the allowed range or set of allowed values. If one or more values are in a field separated by commas, this indicates that more than one port, protocol, or other field value can be used. Only those values explicitly specified will be affected by the table specification; other values not specified follow the default behavior.

Table 7 is a list of IP address ranges, their target geographic destination IDs, and the EPD IDs to which these rules apply.

Table #7 - Table of IP addresses to be routed via geographical destinations

The GDReg_ID field holds the geographic destination ID. A region value of 0 indicates that the IP address (etc.) to be stored locally should be directed to the internet from its local EIP from the EPD. Region values 1 to 300 indicate countries and regions. Higher region values indicate finer granularity. The IP4_Start and IP4_End fields hold the starting and ending IPv4 addresses.

Table 8 is a benchmark of IP addresses for countries and other geographic regions used by the geographic destination mechanism. Due to the large number of IP addresses used, CIDR notation is used.

Table #8 - Benchmarks of IP addresses per region

This table defines the range of IP addresses for nationwide blocks or regional blocks, depending on the granularity used for regional routing. Addresses for geographic destination routing are routed in order before the regional IP address table and are therefore routed first.

The CIPB_ID field holds the national IP address block ID. The CIDR4 column indicates the CIDR number for the range of IPv4 addresses. CIDR stands for Classless Inter-Domain Routing, a notation used to describe IP address ranges. For example, a slash eight (/8) notation represents a block of 16,780,000 IP addresses. A slash twenty (/20) represents 4,096 IP addresses. The Total_IP4 column indicates the total number of IPv4 addresses covered by the CIDR4 range.

53 is a flow chart of an algorithm that controls the routing of traffic from an origin device to an endpoint device.

In the GVN, there is a routing table for the basic level internet route between GVN devices and various other devices, such as EPDs and SRV_APs, over which tunnels can be built. The routing table controls the routing of Level 1 (internet level) traffic through the GVN at Level 3. Sometimes, tunnels may not exist, or if they do exist, they may not be optimal. GVN routes can be mapped to existing and possible GVN routes based on the topology database. All information about basic network segments and links between devices is stored in the GVN database.

The algorithm begins by identifying the target area for a particular GVN traffic flow. Next, a check is performed to see if a path exists through GVN 5306. If not, a new tunnel 5310 is constructed. The next step is to check the health of tunnel 5312. If it is unhealthy, a new replacement tunnel 5310 is constructed. Once a healthy tunnel is available, the route health is checked 5320.

If a route exists in the target area 5322 to the EIP, the route is checked to see if it is the best route for the traffic type. If it is the best route, the route is used 5360.

If the route is not ideal for the data type, a check is performed to see if an alternative exists 5350. If an alternative exists, the best route for the traffic type is taken 5352 and used 5360. When a route is used, the process evaluates the performance of the route 5365. Before the algorithm completes, another process saves performance data in a log via P 5328 regarding server availability, a list of EIPs 5322, and the mapping path used by 5302 to the target zone.

If the test at 5350 determines that the routing is not ideal for the data type and no alternative exists, a new tunnel 5310 will be constructed via path P 5314.

control

The modules required for automatic device collaboration and information exchange in GVN are shown.

The EPD 100 is an endpoint device. The SRV_AP 300 is an access point server located in the target destination area. The SRV_CNTRL 200 is a central server accessible by the EPD and SRV_AP, as well as by other devices that may support the graphical destination mechanism.

Each device, EPD 100, SRV_AP 200, and SRV_CNTRL 300, stores information about itself in a local information repository in the form of lists, files, database tables, records, and other means. This repository also includes information about peer device relationships, stored log records, and other relevant operational information. SRV_CNTRL 200 also has additional storage capabilities and is used to provide information to other devices associated with it and/or to peer devices that may be connected to it, so as to assess the current status and provide guidance similar to centralized control, such as publishing server availability lists and other functions. A neutral API mechanism (NAPIM) can be used to send information between devices and their connected peers and can also be used to update the API itself.

The database on SRV_CNTRL 200 serves as a repository for information about itself and a centralized repository for other devices. There may be many different SRV_CNTRL 200 servers in many locations, acting as a multi-master device. Each database can store specific information, including tunnel information, peer information, traffic information, cache information, and other information. Security and other aspects are managed independently by each device, including heartbeat functionality, trigger scripts, and other mechanisms.

Figure 55

The communication between the EPD 100, the SRV CNTRL 200 and the SRV AP 300 via the paths API-55A1-55A2, API-55A3-55A2 and API-55A1-55A3 via the Neutral API Mechanism (NAPIM) of the GVN is shown.

For tunnels TUN55-1, TUN55-2 and TUN55-3 to be built between EPD 100 and SRV_AP 300, and for tunnels from EPD 100 to other SRV_AP servers such as TUN55-4 and from other EPDs to SRV_AP 300 via TUN55-5, each device in a peer pair requires specific information for each tunnel.

The NAPIM mechanism stores relevant credentials, coordinates, and other information for each side of a peer pair that is employed when building new tunnels via tunnel managers 55110 and 55310. A server availability mechanism 55222 on SRV_CNTRL 300 evaluates the performance of various tunnels, which are tested on the EPD side via tunnel tester 55112 and on the SRV_AP side via tunnel tester 55312. Information from the tests is relayed to connectivity analyzer 55288 on SRV_CNTRL 200. Test results include assigned IP address and port combinations, ports used, results from historical combination usage, results from port spectrum testing, and other relevant information.

The server availability list represents the EPD 100 with a list of IP addresses and ports that can be used by the tunnel manager to build new tunnels. The SRV_AP 300 and other SRV_AP servers mentioned on the list will be notified to expect 55320 and listen for connection attempts made by the EPD 100.

Server availability prioritizes the list of SRV_AP IP address and port combinations based on expected best performance of established tunnels, while also looking at the current load of available SRV_AP servers, the allocation lists balanced to other EPDs, and other available information.

FIG56 illustrates various types of communications available between GVN devices via NAPIM.

Closed loops may be used for NAPIM REQ/RESP communications between known pairs of peers and there are two main types; device to repository 56 - P2C and device to device 56 - P2P.

RESTful URL publication is open access to unknown peers such as general or generally non-sensitive information that can be shared (if that specific action is allowed).

Each defined API action has a flag controlling access via a path type with possible values, another flag regarding whether authentication is required, and other controls. For example, EPD 100 may request a list of available servers and corresponding IP addresses and ports via 56REQ100200 and receive the list from SRV_CNTRL 200 via response path 56RESP100200. Meanwhile, SRV_AP 300 may be notified by EPD 100 via 56REQ100300 or may receive information from SRV_CNTRL 200 via NAPIM, through database replication, via a backchannel, or other messaging.

Figure 57 depicts a set of API calls 57202, 57206, and 57208 between different types of devices within a global virtual network (GVN). Each API call is essentially a round-robin, where a request is sent from a client to a server, and a response is sent back to the client. In most cases, the client can be either end of a peer pair, as long as the other peer has enabled the listening function, thereby acting as a server.

API call group 57202 represents calls from central server (SRV_CNTRL) 200 via path P57202-C, to endpoint device (EPD) 100 via P57202-B, and to access point server (SRV_AP) 300 via P57202-A. This type of communication can exchange information regarding tunnel information, logging information, billing information, device peer pair data, and other forms of related information between the repository databases and file stores on SRV_CNTRL 200 and EPD 100, as well as SRV_AP 300.

There are two types of communication paths between the EPD 100 and the SRV_AP 300. A direct tunnel between them pushes Layer 3 traffic, information, and binary files as packets via path P57206-C. There is also an API call architecture 57206 between the EPD 100 and the SRV_AP 300, implemented via the path P57206-B to 57206 to P57206-A.

The direct connection between the EPD 100 and the SRV_AP 300, via API 57206, can be used for information sharing, collaboration, and verification, among other things. For example, an attempt to restart a tunnel can typically be triggered by one side, with the other side automatically responding and reestablishing it. However, in the event that a tunnel is blocked and cannot be reestablished, the API can be used to send commands to attempt to force a tunnel restart on both ends, and if that fails, information can be shared between the devices. This information may trigger the need to establish a different tunnel between the two devices using new tunnel information, or cause both devices to send queries to the SVR_CNTRL 200 to obtain new tunnel establishment information. Therefore, establishing a communication path between them via API 57206 is very useful.

API call group 57208 represents calls made from CNTRL_SRV 200 and internal backend infrastructure devices and other infrastructure support devices of the GVN via path P57208-C. For simplicity of illustration, some gateway devices are shown in this example embodiment, and other types of infrastructure devices may exist in the GVN that are not shown here and are connected to SRV_CNTRL via this path.

SRV_GW_Email 57310 represents an email server and is linked to 57208 via P57208-B1, then to P57208-C, and thus to CNTRL_SRV 100. Email can be sent and received via the email network access point (NAP) 57401. A dedicated email server allows other devices to focus on their own functions and also provides simplified management, as it is the only device type that needs to be maintained in terms of email server management.

SRV_GW_FIN 57318 represents a financial gateway server that can be used to conduct credit card and other financial transactions with third parties via external API 57501NAP. As with the SRV_GW_Email example, this single-function focused appliance role allows other devices to focus on their core functionality and provides simplified management, as only the SRV_GW_FIN server requires additional management to secure financial transactions with third parties.

SRV_GW_Other 57315 represents other types of gateways between the GVN and other services on the Internet. Communication between these types of gateway servers and SRV_CNTRL 200 is achieved via P57208-B3 to 57208 to P57208-C.

The secondary API path between SRV_AP 300 and SRV_CNTRL 200 is via P57208-A to 57208 to P57208-C and exists for redundancy purposes and for infrastructure-related communications between this peer pair.

Another set of calls from the SRV_AP server may establish a path from SRV_AP 300 to SRV_GW_Email 57310 via a path from P57208-A to 57208 to P57208-B1, a path from SRV_AP 300 to SRV_GW_F1N 57218 via a path from P57208-A to 57208 to P57208-B2, and a path from SRV_AP 300 to SRV_GW_Other 57315 via a path from P57208-A to 57208 to P57208-B3. These may implement API calls for exchanging data directly from SRV_AP 300 to these devices.

API calls transmitted via P57208-A can also represent relayed API calls made by other devices via SRV_AP 300, such as a call from EPD 100 to SRV_GW_FIN 57318 via path P57206-B to 57206 to P57206-A to 300 to P57208-A to 57208 to P57208-B2. In this case, the API call flow implemented through SRV_AP 300 is just another hop in the chain, where the client is EPD 100 on one end and the server is SRV_GW_FIN 57318 on the other end.

API calls and other types of information exchange are critical to the operation of devices in the GVN. Several types of automated infrastructure operations exist. These operations include: keeping device operating system configurations up to date; updating O/S and module software packages from reliable repositories that contain updated software, allowing for easy and predictable patching, updates, and fresh installations; deploying new global virtual network software modules and keeping installed modules up to date; performing controlled replication of the GVN database; keeping the API operation library up to date; and other operations.

On each device, there are background processes and heartbeat functionality where automation and inter-device interaction are required. This includes keeping background processes running, keeping services online, keeping queues online and unblocked, heartbeat functionality, and recording functionality.

Connectivity and fabric structures in a GVN include virtual interfaces (VIFs), tunnels, multiple tunnels, routing, server availability, geographic destinations, DNS, and cache and linked caches.

Tunnel establishment requires up-to-date information, and this information needs to be shared between the client and server; otherwise, the tunnel will fail. Therefore, testing and diagnostics are required, with the resulting data reported for centralized analysis to understand the overall operation of the GVN. Testing and diagnostic information can include: Layer 1 conditions; tunnel connectivity; optimal point-to-point routing on the Internet; Advanced Smart Routing (ASR) for optimal routing through the GVN; and device operational status.

The API may also be used to convey information about itself, such as peer pair information, queue information, transaction logs, security/accounting and other logs, as well as API actions, modes, data structures, and associated scripts on the client or server to process the actions.

Information about the status and configuration of the hosted service can also be transmitted via API calls to SRV_CNTRL or other devices from the device. This information can include service online/offline status, API module online/offline status, and if answerable, the hosting status of the site, database status, Secure Sockets Layer (SSL) certificate status, GVN component status (e.g., whether components such as geographic destinations are running).

Information exchange via APIs has other uses related to security/FW/monitoring/collaboration/information exchange and other mission-critical aspects of GVN. APIs are a powerful medium for information exchange and are self-healing mechanisms for integrity, so they can be deployed across devices.

Figure 58 describes the steps taken by an API call originating from a client device peer (source) 006, sent to a server device 007007B and returned to the client 006006B.

An API transaction is triggered at API Initiate 001. Data is passed to a common class or other type of handler to create an internal payload 002. This internal payload is added to a queue 003, which can be stored in memory, a database, a flat file, or other mechanism. The queue step can be bypassed with an API call that is sent immediately, or it can be set to be sent at a certain time. As part of the client device's 006 heartbeat function, and depending on the priority flag of the API call in the queue, the payload can be processed immediately, at a specific time, or delayed based on factors such as the payload, queue 003 length, network conditions, or other factors. As an item is processed from the queue, an external payload is prepared and associated transaction data 004 is generated for the specific, single-purpose API call. When the external API REQUEST payload is ready to be sent, it is transmitted via a neutral API mechanism 005 and sent to the peer target 007 host (server) API via the Internet Q01 via the path CP01 to Q01 to CP03 or via a secure WAN tunnel Q02 via the path CP02 to Q02 to CP04.

After receiving 008 the request payload RP01, the server 007 will then begin parsing and interpreting it. When processing the request payload RP01, security and data integrity checks are performed, and the outer payload is decrypted to reveal the contents of the inner payload 009. Further security and data integrity checks are performed by comparing the inner and outer payloads. After verification, the payload is passed to the corresponding script to take the specified action 010. Upon completion of the request action, an inner payload for the response is created 011. The outer payload creation 012 and transaction preparation 013 use the same process used to create the API request outer payload RP01 to create the outer API RESPONSE payload RP02. The response is then sent back via the neutral API 014.

API RESP (response) RP02 returns from API server 007 to API client 006 along the same path.

The API RESP RP02 is received back 015 by the peer source API client device 006. The payload is parsed 016 and processed 017. Depending on the API action type, the received data is passed to the API handler script on 006. The entire transaction is logged 018.

If callback 019 is specified 020 , then a new call will be initiated via path P019 and in parallel via path P020 , with the original API call completed at API completion 022 .

If no 021 callback is specified in API RESP RP02, the original call proceeds to termination point 022 via P021 to complete the transaction.

Figure 59 is a flow chart illustrating the interaction between the EPD and the SRV_AP for obtaining geo-destination functionality. Specifically, this figure describes the process flow of the geo-destination mechanism, which begins at the client 000 and follows sequential and sometimes parallel communication paths from CP0 to the endpoint device (EPD 100) at step 12, where the EPD 100 interacts with the access point server (SRV_AP 300).

This process flow ends when the content within the remote region has been pulled to the SRV_AP 300 and then sent back to the EPD 100 via transport and caching within the geographic destination mechanism, and then provided back to the client 000 via path CP203 in step 15.

In step 8, content is pulled in parallel from content servers SRV 803, 804, 802 via CP13, CP14, CP12, and the results are sent back via CP10 for listing and subsequent processing of the data pull.

Steps 1 , 12 , 13 and 15 occur in the original area with respect to client 000 and EPD 100 .

Steps 2, 10, 11 and 14 are steps that occur when transmitting in either or both directions between the EPD 100 and the SRV_AP 300.

Steps 5, 6, and 9 occur on SRV_AP 300.

Steps 3, 4, 7 and 8 occur from the SRV_AP 300, over the Internet in the remote area where the SRV_AP 300 is located, via the EIP (Egress/Ingress Point).

Step 3 is used to perform a DNS lookup on the initial URL, URI, and URN of the content requested by client 000. Step 7 is used to DNS lookup the nested content pulled as part of the initially pulled content.

Figure 60 illustrates device collaboration within a geographic destination. Generally, components are indicated as modules, and the components mentioned on each device include information stored in memory and databases and information exchanged, as well as information communicated via communication paths for API traffic and data transfers, such as file transfers between devices. GVN enables the control of complex automated structures extending across multiple devices working together to achieve a common goal.

The figure shows the components of the EPD 100 and shows the geo-destination mechanism on an endpoint device (EPD).The figure also shows the components of the SRV_AP 300 and shows the geo-destination mechanism on an access point server (SRV_AP 300) in a remote area from the EPD.

The content pull proxy D302 resides on the SRV_AP 300. The CPA D302 receives a target URL/URI from the CDA D102 on the EPD. This target address, which the client wishes to reach, is located in a different region from the client and is the location from which the client wishes to pull content. The CPA D302 transmits the request address to the remote crawler BOT (R.F.BOT 301).

The job of R.F.BOT D301 is to perform a DNS lookup D304 and then use that information to pull the content via Data Pull 301. R.F.BOT D301 collaborates with CPA D302 via CP01 to parse the crawl results and find any additional addresses for ancillary content that can and should be pulled as part of the content. The request is stored in Database D302 for access and further reference by CPA D302 and R.F.BOT D301. The content file list L301 is transferred from R.F.BOT D301 to CPA D302. The data file content is transferred from Data Pull 301 via R.F.BOT D301 to Cache Manager D303. The pulled files are sent to Cache Manager D303 for transfer as a file aggregate or as individual files.

Depending on the distance from the origin to the geographic destination area, file type, and QoS, files pulled from the caches may be aggregated into a single file that is transmitted uniformly through the chained caches or may be independent files that are sent as parallel concurrent streams.

There are multiple optional paths to remote areas. Data can be transferred via the paths between the API and TP01 to TP02, the path between TP01 and TP03, and the path between TP02 and TP03. Data files can also be transferred through the GVN via paths CP38, CP39, or P06 to CPBB, and so on. CP38 is a tunneled path from SRV_AP 300 to SRV_AP D555 via GVN D888. CPBB is a trunk path between SRV_AP D555 and SRV_AP 300, relaying path P06 via SRV_AP D505. CP39 is a file transfer path from cache 701 to EPD 100 via SRV_AP D555 on the GVN. CP02 indicates the possibility of a direct connection path between SRV_AP 300 and EPD 100.

Alternative paths to remote areas provide options for traffic to flow via the best route based on current conditions, network segment properties and how these properties contribute to optimal transmission, data type, and other factors.

Figure 61 illustrates how a globally distributed parallel file system (PFS) can be connected via a GVN. Specifically, this figure illustrates how a globally distributed parallel file system (PFS) can allow seamless access to one of three 61308, 61318, or 61328 PFS storage nodes using local RDMA access through the GVN tapestry over the top (OTT) of various non-local network fabrics, achieving the required quality of service (QoS) and conforming to the high-performance computing (HPC) principles required for this functionality. PFS 61308 is an example of a PFS instance in a client LAN behind an EPD connected to two other PFS instances "in the cloud," where local RDMA over the IB between all three PFS storage nodes allows true parallel access regardless of the network type at the underlying segment. Link 61CP06 is the primary internet connection between EPD 100 and SRV_AP 300, and TUN1 runs over the top of 61CP06. 61CP10 is within the IDC or OTT internet. PFS 61308 is connected to PFS 61318 via the path 61CP08->8CP02->8CP06/TUN1->8CP10->8CP12->8CP18, which represents a short distance within the area. These devices are all located in the same high performance zone.

The SRV_AP 300 is connected to the SRV_BBX 61310 via 61CP10 and both are located within the same global node.

The PFS 61318 is connected to the PFS 61328 via the SRV_BBX 61310 which is connected to the SRV_BBX 61320, which represents long distance communication via the global node to global node of the GVN.

The scope of the present invention is not limited to the specific embodiments described herein. In fact, in addition to what is described herein, a person of ordinary skill in the art can clearly understand other multiple embodiments of the present invention and modifications to the present invention from the above description and the accompanying drawings. Therefore, such other embodiments and modifications are expected to be within the scope of the present invention. In addition, although the present invention has been described in the context of at least one specific embodiment in at least one specific environment for at least one specific purpose, a person of ordinary skill in the art will recognize that the usefulness of the present invention is not limited thereto, and the present invention can be beneficially implemented in any number of environments for any number of purposes. Therefore, the appended claims should be interpreted in light of the full breadth and spirit of the present invention as described herein.

Claims (10)

1. A global virtual network system, comprising: First equipment; Second equipment; Multiple intermediate access point servers form multiple end-to-end tunnels connecting the first device and the second device; and The control server receives information from at least one of the plurality of intermediate access point servers and selects one of the plurality of end-to-end tunnels for communication between the first device and the second device based on the information. The information described therein may include: client/server topology and settings; the Internet protocol and port for each endpoint the tunnel will use; tunnel metrics and information used for its operation, including the size of the maximum transmission unit and the protocol; information about the security protections used by the tunnel, including keys and passphrases; and information for protecting information exchange prior to tunnel establishment, including Secure Sockets Layer certificates. 2. The global virtual network system according to claim 1, wherein at least one of the first device and the plurality of intermediate access point servers is configured to perform a Domain Name System lookup to locate the second device. 3. The global virtual network system of claim 1, wherein at least one of the first device and the plurality of intermediate access point servers is configured to perform a Domain Name System lookup from a cache to locate the second device. 4. The global virtual network system according to claim 1, wherein at least one of the plurality of intermediate access point servers is configured to cache content. 5. The global virtual network system according to claim 1, wherein at least one of the first device, the second device, and the plurality of intermediate access point servers is configured to perform intelligent routing. 6. The global virtual network system of claim 5, wherein the intelligent routing is based on at least one of optimal bandwidth, lowest latency, fewest hops, and no packet loss. 7. The global virtual network system according to claim 5, wherein the intelligent routing is based on at least one of real-time statistics and historical statistics. 8. The global virtual network system according to claim 1, wherein at least one of the first device, the second device, and the plurality of intermediate access point servers is configured to perform firewall services. 9. The global virtual network system according to claim 8, wherein the first device provides firewall services between the first device and the plurality of intermediate access point servers. 10. The global virtual network system according to claim 8, wherein the first intermediate access point server among the plurality of intermediate access point servers provides firewall services between the first device and the other intermediate access point servers among the plurality of intermediate access point servers or the second device.