CN115834534A - System for Global Virtual Networks - Google Patents

Abstract

The present invention discloses systems and methods for connecting devices via a virtual global network. In one embodiment, the network system may include a first device in communication with a first endpoint device and a second device in communication with a second endpoint device. The first device and the second device are connectable 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.

Description

System for Global Virtual Networks

The patent application of the present invention is a divisional application of the patent application for invention with the filing date of January 28, 2016, the application number of 201680007187.5, and the title of the invention "system and method for global virtual network".

This application asserts 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, and U.S. Provisional Patent Application No. 62/151,174, 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, which are hereby incorporated by reference middle. 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 networking and, more particularly, to the configuration and operation of Global Virtual Networks (GVNs).

Background technique

Although "last mile connectivity" has improved tremendously in recent years, there are still long-distance connectivity and throughput issues due to distance, protocol limitations, peer-to-peer operations, interference-related issues, and other issues and threats. GVN provides clients with secure network optimization services on top of their standard Internet connections.

This application provides an overview of the GVN components and describes related technologies that can be used as GVN elements. GVN elements can operate independently or within the GVN ecosystem, such as employing 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 a standalone deployment using some or all of GVN's components, or can be quickly deployed as a standalone mechanism on top of an existing GVN to take advantage of its benefits.

Humans are able to perceive latencies of 200 milliseconds or more because this is generally the average human reaction time to events. If latency is too high, online systems such as thin clients to cloud-based servers, customer relationship management (CRM), enterprise resource planning (ERP) and other systems will perform poorly and may even stop functioning due to timeouts. High latency combined with high packet loss can render the connection unusable. Even if the data gets through, at a given moment, being too slow can lead to a poor user experience (UX) and in these cases, users may end up rejecting the conditions, effectively viewing the poorly delivered service as useless.

In order to solve some of these problems, various techniques have been developed. One technique, WAN optimization, typically involves a hardware (HW) device at the edge of a local area network (LAN) that establishes a tunnel to another WAN-optimized HW device at the edge of another LAN, thereby creating a link between the two hardware devices Form a wide area network (WAN). This technique assumes that two devices are connected to each other via a stable connection. WAN optimizers strive to compress and protect data flows, which often results in speed gains. WAN-optimized business drivers are used to save data volume sent, thereby reducing data transmission costs. The downside of the technology is that it's usually point-to-point and can be laborious when there's a poor connection between two devices, since there's little to no control over the path of traffic through the internet between the two. To solve this problem, users of WAN optimizers often choose to run their WANs over MPLS or DDN lines or other dedicated circuits, incurring additional costs and often necessitating rigid, fixed point-to-point connections.

In the market at the time of writing this patent, some vendors are focused on selling hardware, not on connection services over the Internet between their hardware devices. Other suppliers are service providers who may provide simple endpoint devices or software that can be installed by the customer on the customer's own equipment to connect to the service provider's cloud The main focus of these providers is service delivery.

Direct links such as MPLS, DDN, dedicated circuits, or other types of fixed point-to-point connections can provide connection quality and quality of service (QoS) guarantees. These links are expensive and typically take a long time to install due to the physical wiring required from the POP on each side of the connection. Point-to-point topology works well when connecting from within one LAN to resources in another LAN via this directly connected WAN. However, when the gateway (GW) to the general Internet is located at the LAN at the LAN end, for example at the corporate headquarters, then traffic from remote LANs in subsidiary countries can be routed to the Internet through the GW. The slowdown will occur as traffic travels back across the Internet to servers in the same country as the affiliate. Traffic then has to flow from the LAN over the WAN to the LAN where the GW is, then over the Internet back to the server in the originating country, then back over the Internet to that GW, and then down a dedicated line to the client device within the LAN. In fact, only a small fraction of the global latency to access this nearby site should be needed, which would double or triple (or worse) the global transit time to access this nearby site. To overcome this problem, alternate connectivity of another Internet line with appropriate configuration changes and added 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. They are usually encrypted and can provide compression and other logic in an attempt to improve connectivity. Little to no control over the routing between the two points, as they rely on the policies of various intermediary actors on the Internet that transmit their own traffic through their networks and communicate with other carriers and/or networks Operators are in a peer-to-peer relationship. Firewalls and routers, switches, and other equipment from several equipment vendors often have tunneling options built into the firmware.

A software (SW) based virtual private network (VPN) provides privacy via a tunnel between a client device and a VPN server. These have encryption advantages and in some cases also provide compression advantages. But again, there is little to 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 device at the destination. These are usually point-to-point connections that require each device using the VPN to install client software and require some technical ability to maintain each device's connection. Performance will be good if the VPN server exit point is in close proximity to the destination host server or host client via a good communication path. If it is not close together, it will significantly restrict performance and cause dissatisfaction in usability. VPN users often need to have to disconnect from one VPN server and reconnect to another VPN server to gain premium or local access to content from one region as opposed to content from another region.

Global Virtual Network (GVN) is a type of computer network on the Internet, which uses a network of devices distributed around the world that are securely linked by advanced tunnels to provide global security network optimization services; via application programming interfaces (APIs), Database (DB) replication, and other methods of collaboration and communication. Traffic routing in the GVN is always done via the optimal communication path managed by Advanced Smart Routing (ASR) driven by an automated system that combines builders, managers, testers, algorithm analysis, and other methods to Adapt to changing conditions and learn over time to configure and reconfigure the system.

GVN provides services on top of one or more conventional Internet connections to provide safe, reliable, fast, stable, precise and centralized parallel connectivity. These benefits are achieved through the compression of the data stream that passes through the connection of multiple wrapping, masquerading and encrypted tunnels between the ETO and the access point server (SRV_AP) next to the EPD. Continuous monitoring of connection quality between EPD and SRV_AP.

GVN is the installed software (SW) hardware (HW) endpoint device (EPD), database (DB) and other automation modules of the GVN system, such as neutral application program interface mechanism (NAP top), back channel manager, tunnel management controller, and a combination of further features that connect EPDs to distributed infrastructure devices such as Access Point Servers (SRV_AP) and Central Servers (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 routing 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 zero user interaction or intervention.

Advanced intelligent routing in the EPD and SRV_AP ensures that traffic flows from origin to destination via the most optimal path through the GVN's "Layer 3" as simply as possible. Client devices connecting to the GVN treat this third layer as a normal Internet path, but with fewer hops, better security, and in most cases , the delay time is shorter. Logic and automation operate at the "second layer" of the GVN, 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. Layers 3 and 2 of GVN exist on top of GVN's operational "Layer 1" which interacts with underlying Internet devices.

Contents of the invention

The present invention discloses systems and methods for connecting devices via a virtual global network. The network system may include a first device in communication with a first endpoint device. The network system may include a second device in communication with a second endpoint device. The first device and the second device are connectable 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 optimal 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.

Description of drawings

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

Figure 1 shows a block diagram of the technology used and implemented by the Global Virtual Network ("GVN").

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

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

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

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

Figure 6 illustrates some example threats and problems that exist on the Internet.

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

Figure 8 shows the operation of the proxy server.

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

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

FIG. 11 shows the flow of information between devices of the global virtual network.

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

Figure 13 shows a GVN topology including backbone segments on Internet or dark fiber.

Fig. 14 shows a distributed firewall (FW) in the cloud implemented by GVN.

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

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).

Figure 17 shows a GVN using a hub and spoke topology with backbone segments and octagonal routing.

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

Figure 19 shows the connectivity between various devices within the GVN.

Figure 20 shows how the GVN module interacts with the device.

Figure 21 shows additional details on how the GVN module interacts with the device.

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

Figure 23 shows multiple tunnel connectivity between an endpoint device (EPD) and an access point server (SRV_AP).

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

Figure 25 illustrates strategic positioning of infrastructure to enhance performance.

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

Figure 27 shows how tables in the databases of various GVN devices are related to each other.

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

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

Figure 30 shows the establishment of a series of encrypted tunnels between the client (C) and the server (B).

Figure 31 shows the information flow required by the two peers in a peer pair.

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

Fig. 36 shows that multiple network structures are jointly woven into a network blanket framework (Tapestry).

Figure 37 shows the communication paths for automatic device cooperation in GVN.

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

Figure 39 shows bridging two LANs into a Wide Area Network (WAN) via two or more EPDs.

Figure 40 shows the Multi-Perimeter Firewall Mechanism (MPFWM) running on the 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 global Internet flow 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 Advanced Smart Routing (ASR) features and elements of the GVN's Geographic Destination mechanism within an Endpoint Device (EPD).

FIG. 48 shows an example of multiple parallel-type traffic paths taken via the 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 diagram of Advanced Smart Routing (ASR) within a Global Virtual Network (GVN).

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

Figure 53 is a flow diagram of an algorithm controlling the routing of traffic from an origin device to an endpoint device.

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

Figure 55 shows communication between EPD, SRV_CNTRL and SRV_AP via GVN's Neutral API Mechanism (NAPIM).

Figure 56 shows various types of communication available between GVN devices via NAPIM.

Figure 57 depicts a set of API calls between different types of devices within a global virtual network (GVN).

Figure 58 depicts the steps taken from a client device through an API call sent to a server device and back to the client.

Figure 59 is a flowchart illustrating the interaction between the EPD and the SRV_AP for obtaining geographic destination functionality.

Figure 60 depicts device collaboration within a geographic destination.

Figure 61 shows how the globally distributed Parallel File System (PFS) operates within GVN.

Detailed ways

overview

Figure 1 shows a block diagram of the technology used and implemented by the Global Virtual Network ("GVN"), which includes the GVN core element G0, the GVN module G100 and the technology G20CLGVN core including the mechanism overview G1 implemented by the global virtual network GVN And its constituent parts, namely topological G2 layer, structural G3 layer, logic G4 layer and control G5 layer. GVN core GO also includes relative to GVN elements G6 and the relationship with these GVN elements.

GVN may include plug-ins and/or stand-alone GVN modules G100 including, but not limited to: Neutral API Mechanism (“NAPIM”) module G102 described in PCT/US16/12178; Destination ("Geo-D") module G104; Advanced Smart Routing ("ASR") module G106, connection module G108 and other modules G110 described in US Provisional Patent Application US 62/151,174.

GVN also provides platforms that enable other technologies, including but not limited to: Network Tapestry G202; MPFWMG204; Network Slingshot G206; Network Beacons G208, Granularityofatick G210 and others G212. These are described in US Provisional Patent Application No. 62/174,394, US Provisional Patent Application No. 62/266,060.

The GVN modules ( G100 ) and technologies enabled by the GVN ( G200 ) may operate as integral parts of the GVN on top of an existing 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 sketchy understanding of how the Internet works. Host source 2100 is a starting point and represents a client device, which may be a computer, mobile phone, tablet, laptop, or other such client. This client connects via the Internet 2200 to a host server 2300 to send or retrieve content, or to another host client 2303 to send or receive information.

A less technically knowledgeable user might assume that traffic is following path 2P002 to the host server, not even understanding that their data will be transiting through the Internet. Alternatively, they may think that traffic is flowing directly to another client device via path 2P006.

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

A more technically literate user will further understand that when an email is sent, this email will leave its client device 2100, travel via path 2P004 to the Internet 2200 and then via path 2P202 to email server 2202. The recipient of the email will then request to retrieve the email via its host client 2302, along the path 2P104 to the Internet, and then along the path 2P204 to the mail server 2202.

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

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

Content requests 3000 or push streams from the host client (C) 3100 to the host server (S) 3300 as files or data streams or data blocks from the host client (C) 3100 to the host server (S) 3300. A response or content transfer 3002 is returned from host S to host C as a file or data stream or data block. 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 via a Uniform Resource Locator (URL) or other network reachable address to the remote host server(s).

The initial connection from the host client (C) 3100 to the Internet 3206 is shown as 3P02, the connection from the host client (C) to a directly faceable point of presence (POP) 3102. 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 may be referred to as a last mile connection. Points of Presence (POP) 3102 represent the connections from endpoints to the Internet provided by Service Providers (ISPs) via their networks and interconnections. This could be, but is not limited to, cable, fiber optic, DSL, Ethernet, satellite, dial-up and other connections. If the URL is a domain name rather than a numeric address, the URL is sent to a Domain Name System (DNS) server 3104 where the domain name is translated to an IPv4 or IPv6 or other address for routing purposes.

Traffic from host client (C) 3100 to host server (GD) 3300 is routed through the Internet 3206, which represents transport between POPs (3102 and 3302), including peer-to-peer, backhaul, or other transport at network boundaries.

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

A lookup from a URL or hostname to a numeric address via the Domain Name System is now the standard on the Internet, and the system assumes that the DNS server is integral and that the DNS server results are current and trustworthy.

Figure 4 is a diagram illustrating the upstream and downstream paths taken to transmit data from a host client device (C##) to another host client or host server device (S##). Numbers used on equipment labels such as C01 or S08 are for identification purposes to locate the individual equipment and the numbers themselves do not imply or imply that one equipment is larger or more powerful than another equipment.

Figure 4 shows a host client device (C##), a host server device (S##), a switch (SW##), a router (a, a region router (RR##), an edge router_#), a core router ( CR##). A communication path or pipe (P##) refers to the connection between two devices and the line thickness is used to indicate the size or bandwidth capacity of the pipe. The thinner the wire, the lower the megabits per second (Mbps). The thicker the wire, the higher the amount in Mbps or Gigabits per second (Gbps). The distance of P## is not drawn to scale and does not consider hop count or time to live (TTL) and latency or round trip time (RTT) when referring to P## between devices.

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

The connection P05 between the LAN and its Internet Service Provider (ISP) Point of Presence (POP) R01 may also be referred to as the "last mile". This POPR01 is the hub connecting the other spokes P06, P07, P08 and P09 to the corresponding switches of other clients such as SW02, SW03, SW04 and SW05. There is also an upstream path P16 to the area router (RR) RR02.

This hub-and-spoke topology is shown for POPR02, R03, and R04, which communicate with corresponding switches (e.g., 3x6, 5x7, 5x8, 5x9, 5110, 5111, 5112, 5113, 5114, 5115, 5116, 5117, 5￥18, SW19, SW20), P10, Pll, P12, P13, P14, P15, P51, P52, P53, P54, P55, P56, P57, P58, P86) and their connections (eg, P17, P18, P46, P28) to their area routers (eg, RR02, RR03, RR04, RR05).

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

Both POPR01 and R02 are 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 the networks of two or more different ISPs, with potentially other carrier peering points in between, depending on the owner of the infrastructure through which the traffic travels. Traffic through the backbone will be carried by the highest potential capacity pipe. The traffic between the router R01 and the router R04 can also be transmitted via the path P16->P41_>P44->P23->P27->P28. Although this path may appear shorter, the efficiency of this second path in controlling edge router ER03 to carry traffic between the two other ISPs may be due to pipe size, intermediary devices, intermediary ISP peering relationships and policies lowest. There may also be pass points between them.

Another feature illustrated 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 LAN. The switch SW13 is simultaneously connected to the router R03 via P53 and to the area router RR04 via P46. Connection P46 may describe a leased line or direct digital connection for enhanced connectivity.

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

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

Figure 5 is a diagram illustrating boundary exchanges in the path taken to transmit data from a host client device (C##) to another host client or host server device (S##). This can be very similar to Figure 4, with one exception. On the backbone between the core routers CR01 and CR02, at specific points on the peering path between them, there is a series of border switches 400, each of these switches having a limited capacity relative to the backbone as a whole , and there may be congestion events between these switches.

Figure 6 illustrates some example threats and problems that exist on the Internet. The network data path has been simplified to provide an overview of connectivity and focus on threats from endpoint devices (EPDs) and additional threats from intermediate devices.

A request from host client device C002 to retrieve content from host server device 207 should take the path P109->P105->P103->P102->P101 and be transmitted via Internet 101 to CP01->CP02->P205->P207. Legitimate Internet Data Centers (IDCs) may have load balancers that send traffic to healthy host servers 207 (via P207) or infected host servers 206 (via P206). An infected host server may send malware or viruses or other objectionable content back to client device C002.

Another threat is to redirect legitimate traffic to a spoofed host server 114 . The traffic should take the path between C02 and 207 as described above, however, the tricked server can suck away the legitimate traffic. The traffic will still take paths such as P109->P105->P103->P102->P101 and pass through the Internet 101, but the traffic will not be transmitted to the legitimate server via CP01, but to the spoofed server 114 via P113 to P114.

A spoofed server can be designed to phishing for confidential information or credentials or other data by appearing to Internet users as the real server. The average user cannot distinguish between a legitimate server and a spoofed server. Third parties may also use spoofed servers to prevent legitimate traffic from being delivered to 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, thereby translating Uniform Resource Locators (URLs) such as the domain name www.thisdomain.com into numerical IP addresses such as IPv4 or IPv6 addresses for access from host clients The device's traffic finds its way to the host server device.

If a DNS server such as 212 or 116 is poisoned 112 or spoofed 114, the translated numeric IP address may become incorrectly directed traffic being sent to an illegitimate or compromised destination device. Another way DNS can be compromised on the Internet is by devices not delivering results or delivering incorrect results and acting improperly. Propagating changes from the primary DNS registrar to the DNS servers also requires clear and efficient connectivity, otherwise indexing results may become stale or erroneous. An example of how to secure and secure DNS lookups will be illustrated with a secure DNS (DNSSEC) server 110 and its connectivity via P19. This relies on the ability of client devices to connect to DNS server 110 without their "handshake" being interrupted.

Even when both the host client and host server devices are operating correctly, since the Internet is not encrypted, there is still a very real risk of inserting a sniffer or interception at an intermediate point in the communication path to the host server such as the mail server 203 Device 204 may intercept and capture data. Although traffic destined for the mail server 203 should flow from the Internet 201 to the mail server 203 via the P202 to POP 202 to P203 path, the sniffer or intercepting device 204 will pass the traffic through the 204 via P204 and go to P222. Such interference is very difficult to detect unless the IP address of the hop in the communication path can be definitively 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 set of infected devices 213, 215, 216 controlled by command and control (C&C) servers such as 214. Collectively, these devices can perform bulk attacks such as Distributed Denial of Service (DDoS), where host server devices can be overwhelmed with too many requests flooding their capacity, making it slow to isolate requests from legitimate host client devices Or it can't be parsed at all.

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

B0T networks are also distribution mechanisms for spam (SPAM) emails, phishing emails, malware distribution, and other malicious purposes.

National firewalls such as 304 block the free flow of information. These firewalls can be used as a censorship tool to block what the state considers bad traffic. It can also be used as an interception device to covertly steal industrial, commercial or other secrets. Depending on the time of day, total Internet traffic, and the health of these countries' firewalls, traffic passing through them may suffer from latency or packet loss, or be shaped to maximize bandwidth and become a bottleneck, or a combination of all of the above or even other issues.

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

Figure 7 illustrates content delivery network (CDN) resolution and delivery of region-specific content. A content delivery network (CDN) can offer significant advantages in speed and flexibility and provide load balancing when serving content to clients. A content request 7REQ000 flows from the host client (C) 7100 to the host server (B) and a content delivered response stream 7RESP002 returns from the host server (S) to the host client (C) 7100 as a file or data stream or data block.

Host Client (C) 7100 may 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 the Host Server (S). The host client (C) requests access to content provided by the host server (C) via a Uniform Resource Locator (URL).

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

In the case of a CDN infrastructure, the CDN map marker 7200 operates in coordination with the CDN control server 7202 . The CDN Mapping Indicia 7200 and CDN Control Server 7202 determine the region where the host client device is located and which CDN server the host client should connect to for the provided content. 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. The host client 7100 in area C will connect to the CDN server 7500 in area C via the POP of the server in the server POP 7400 in area C.

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

To illustrate this figure, a region is defined as a geographic area that is distinct from another geographic area. It does not necessarily mean a large area but may have a large area, and it may also mean a large distance from one area to another or they may be very close to each other. The point is that clients in one region will receive content via a CDN server from that region but not from another.

In this example embodiment, the content of each area is different from that of other areas. Between the CDN servers 7500, 7502, and 7504 and the origin server 7600 are content region servers 7700, 7702, and 7704, which publish region-specific content to the CDN servers in each region, which in turn serve it to them Clients in the corresponding region of the .

When a client 7100 in one zone, say zone C, wants to get content served by a server 7502 or 7504 from another zone, no matter what they do, the client is only served content from the zone they are in. Contents of server 7500. They cannot access other content, even if they attempt to force a connection to a content server in the region from which they expect to receive content. They keep getting content from their locale without selection. The local DNS lookup 7104 resolves only to the IP of the CDN server 7500 in the area. This may be due to the fact that the global IP address is only mapped to the CDN in the local area (in the case of global IP) or another reason. The result is that the client may be geo-blocked at 7P404 or 7P402.

Normal connections via the 7P008 based on the current geographic location are not blocked and traffic flows in such a way that the host client 7100 receives content for that geographic location via the host server 7500.

Traffic stops at 7P402 and/or 7P408 and the host client is denied content from remote geographic destinations for destinations different from the current geographic location 7502 and 7504. 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, or receive no content or receive an error message or simply not expect content.

Figure 8 shows the operation of the proxy server. A content request or push 8REQ000 flows from the host client (C) to the host server (S) as a file or data stream or data block. Content delivery 8RESP002 is returned from the host server (S) to the host client (C) as a file or 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 will pass 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. Proxy Client software connects to Proxy Server 8306 via encrypted or unencrypted tunnel, from Gateway GW8102 to Point of Presence (POP) 8200 via path 8P02, to WAN 8308 (part of the Internet) via path 8P04, to remote Proxy server 8306 in the zone. Traffic leaves the proxy server 8306, enters the open internet 8300 via path 8P16 and goes 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 that traffic as coming from the IP address and geographic location of the proxy server. If the IP is in the same zone defined by the server in the target zone, the desired content will be served. To help with this localization, the proxy server will typically connect to a DNS server 8404 in the same zone as the proxy server.

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

The baseline from H11 to EH17 describes the number of point-to-point hops. The number of hops from H13 to EH15 is assumed and provided for illustration purposes, and the number of hops in real connection paths may be more or less. The number of hops from 9A2 to 9A1 to 9TUN to 9B1 to 9B2 for a client employing tunnel 9TUN will be about four or five visible hops.

This exemplary embodiment describes a scenario where LAN9A2 is connected to the network of one Internet service provider 9ISP-1 through its gateway 9A1 and LAN9B2 is connected to another Internet service provider 9ISP-3 through its gateway 9B1. This exemplary embodiment further illustrates that 9ISP-1 is not directly peered with 9ISP-3. Both 9ISP-1 and 9ISP-3 require that their network traffic in both directions must be transmitted through the network of another Internet Service Provider 91SP-2. The interconnection between 91SP-1 and 91SP-2 is defined as peer point 9PP-01 and the interconnection from 9ISP-3 to 9ISP-2 is defined as 9PP-02.

The point of this example embodiment is to illustrate that on the Internet, it is common for third party Internet service providers or equivalent providers such as backbone or backhaul providers to carry other Internet service providers' traffic. 9ISP-1 or 9ISP-3 has little to no control over how 9ISP-2 passes its own traffic. Although 9ISP-1's customer 9A2 can complain about service problems directly to their supplier 9ISP-1 and 9B2 can directly complain to 9ISP-3, if the problem is about 91SP-2, there is little that 9A2 or 9B2 can do to directly Affects 91SP-2.

Potential congestion points can occur on any device, but since 9PP-01 and 9PP-02 are peers, they are areas of concern. Limited control over routing and quality of service for all connections. As a result, point-to-point tunnels may struggle to maintain a high-quality, stable connection over distance, especially if there is some traffic passing through a third-party network.

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

With respect to device range 1080, GVN protects client privacy of its data, network traffic, credentials, peer pair information, and protects physical devices from intrusion, including proprietary code from tampering or theft, and other threats.

System-wide 1090 needs to protect against intrusion or other malicious traffic such as DDoS attacks, against misuse, routing around sub-optimal devices or paths, balancing and spreading loads and preventing resource exhaustion, IP address or other global issues.

The focus of the communication range 1098 is to push the traffic path through the GVN mainly through the traffic tunnel TUN. It also covers the entry point (EIP) between the GVN's external network and internal network. It protects against traffic hijacking, man-in-the-middle attacks, poisoning sources (such as bad DNS, etc.), and other threats. Furthermore, tests on the quality of individual network segments and their properties enable GVN to understand full path QoS and bypass issues.

Device coordination 1089 security features are in place to protect the operational integrity of individual devices within the GVN. Secure return channels, anti-intrusion mechanisms, DNS security nets, various database protections such as spin buttons, neutral API mechanism (NAPIM), automatic testing, updates, peer-to-peer relationships, authentication and other modules ensure that system integrity is maintained.

FIG. 11 shows the flow of information between devices of the global virtual network. A central repository consisting of a database B200 and a file store HFS200 resides on a central server (SRV_CNTRL) 200 .

Communication paths between devices labeled P### may represent API calls, database replication, direct file conversion, combinations such as database replication through 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 with peer pairs and privileged relationships with each other.

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

In some cases, devices will share the information loop, such as EPD100 can request information from SRV_CNTRL200 via 11P100200, and the request will be sent back to EPD100 via 11P200100.

In other cases, one device can report information related to other devices, such as SRV_AP 300 reports to SRV_CNTRL200 via 11P300200, and SRV_CNTRL200 then sends information to EPD100 and SRV_AP300 via 11P200100, and sends information via 11P200300 outside of the reporting SRV_AP300 other SRV_AP300, and send information to other devices 11500 via 11P200500.

In other cases where a full loop is not required, such as sending logging information from a device such as EPD 100 to SRV_CNTRL 200 via 11P100200, this information does not need to be forwarded further. However, the logging information may later be moved from the repository on SRV_CNTRL200 to the Long Term Logging Storage Server 11500 via 11P200500.

There is a direct link 11P100300 between device EPD100 and SRV_AP300. Direct link 11P300500 is from SRV_AP300 to other device 11500. A direct link involves communication between devices that does not require the participation of the SRV_CNTRL 200.

Push information from SRV_CNTRL 200 may be RSS feed information published via 11P306 or other types of information. The API from SRV_CNTRL200 can be a traditional API transaction, or a RESTful API call that issues a request via 11P302REQ and receives a response via 11P302RESP. The presented push information and API elements are used to illustrate devices that do not share peer-pair relationships, privileged status, and/or similar system architectures with GVN devices.

Figure 12 depicts the stack used to support the automation of some devices in GVN. Specifically, this figure shows the modules required for automation device cooperation and networking, and operating system (O/S) management.

EPD100 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 EPDs and SRV_APs, as well as by other devices or other GVN modules, components or servers that may support the graphical destination mechanism.

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 and records, and otherwise. This repository also includes information about peer device relationships, storage logging, and other relevant operational information. The SRV_CNTRL200 also has additional storage capabilities and its role is to provide information to other devices related to it and/or to peer devices that may be connected to it, in order to evaluate the current status and provide guidance similar to centralized control, such as publishing a list of server availability and other functions. The Neutral API Mechanism (NAPM) can send information between devices and connected peers of those devices, and can also be used to update the API itself.

Database S293 on 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_CNTRL200 servers in many locations acting as multi-master devices. 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 functions, trigger scripts, and other mechanisms.

GVN software D196, D296, D396 includes tunnel builder/manager, virtual interface manager, automatic intelligent routing, testing modules, security, logging and other functions. Figure 11 also shows operating system (0/S) level packages D195, D295, D395 and includes hardware and software drivers, drivers, installed packages, including their dependent software packages, and system hardware components Other projects built on .

Figure 13 shows a GVN topology including backbone segments on Internet or dark fiber. International Patent Application No. PCT/UJS15/64242, entitled "SYSTEM AND METHOD FOR RETRIEVAL OF CONTENT FROM REMOTE NETWORK REGIONS" (SYSTEMANDMETHODFORCONNTENTRETRIEVALFROMREMOTENETWORKREGIONS) discloses a feature in which multiple files are aggregated into larger files and "Chained caches" are sent from one geographic area to another via file transfers. To/achieve this advantageous feature, file transfers need to be as fast as possible. As a transfer method for groups of multiple data payload "files", The information slingshot method of the present invention moves larger data blocks from one side of the world to the other more quickly than prior art methods.

Referring to Figure 13, a plurality of 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).

SRV_BBX 1372 in zone or zone ZD20 can be connected to SRV_BBX 1380 in another zone or zone ZD30 by dark fiber optic 13220 via dark fiber optic connection 13P220. SRV_BBX 1372 writes files directly to Parallel File Storage PFS 1382 via Remote Direct Memory Access (RDMA) via 13P220, bypassing SRV_BBX stack 1380, and via path 13P82. SRV_BBX 1380 uses the present invention to bypass SRV_BBX stack 1372 via 13P220, and via Remote Direct Memory Access (RDMA) writes files directly to the parallel file storage PFS1374.

Path 13P210 may be IPv4 or some standardized Internet protocol through 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 shows that various types of network structures can be combined into a larger network blanket framework (Tapestry). These structures can be stitched together seamlessly, as described in US Provisional Patent Application No. 62/174,394. This can be a stand-alone approach or integrated as a network segment within a larger network path consisting of multiple network segments. This example embodiment shows the topology of a Global Virtual Network (GVN), its various devices, communication paths and other embodiments. It shows how various geographical areas or districts or regions are linked together by various types of paths.

Fig. 14 shows a distributed firewall (FW) in the cloud implemented by GVN. Due to the nature of the GVN's topology, device-to-device communication, and secure traffic paths, firewall mechanisms can be cloud-based and also virtualized. With firewall-facing hops 144 flowing to and from the GVN via an entry-exit point (EIP) of the open Internet 14000, there may be a cloud firewall (CFW) load balancer 144LB capable of distributing data such as 144-2, 144, 3 and other cloud firewall resources, etc.

This on-demand scalability provides numerous advantages to 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, marker and other characteristics of the attack, so that the cloud firewall can realize and prepare to defend against the attack when the target is shifted. Furthermore, information about past and current attacks can be shared to other CFW instances via GVN's Neutral API Mechanism (NAPM) to enable global threat awareness. This also provides the advantage of running multiple types of FW mechanisms simultaneously, as described with reference to FIG. 15 .

Figure 15 shows a Multi-Perimeter Firewall (MPFW) AVN Tunnel 15TUN0 in the cloud powered by a global virtual network between the top of the Internet between an End Point Device (EPD) 15100 and an Access Point Server (SRV_AP) 15300 next to the EPD 15100 on (overthetop, 0TT).

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 next to the SRV_AP15300; and 15M3 , which is another boundary at the same data center as SRV_AP15300 or at another location next to SRV_AP15302.

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

Each SRV_AP15300 and SRV_AP15302 may represent one or more SRV_AP devices that may be simultaneously connected to an EPD15100 and/or EPD15130 via one or more tunnels.

Three types of firewalls are described in this example embodiment. FW local 15442 is an example firewall that clients can use to protect their local area network (LAN) from Internet-based threats. This is usually between the EPD15100 and LAN15000. The FW15442 provides features such as IP address and port blocking, forwarding, and other functions. The other two types of firewalls shown are the FWSPI15446 at 15M3, which provides Stateful Packet Inspection (SPI), and the FWDPI15444, 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 for patterns, or matches IP addresses or ports or other information from a list of known threats to the current packet flow. As you can tell from the name, DPI looks more deeply at the entire packet, and in the case of multipart, multipacket transfers, it will look at the compilation of a series of packets to gain further insight into the data being transferred.

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

GVN provides the opportunity to distribute these FWs at multiple points in the cloud. And also without impeding traffic flow for various types of firewalls to operate in tandem with each other.

By positioning the FWSPI15446 at 15M3, the nearest edge of the Internet 15302 via the remote EIP15310, it is possible to defend against large amounts of attack traffic from known source IP addresses or with identified malicious headers. Traffic flows from SRV_AP15302 to FWSPI15446 via 15T10 and back via 15T12. FWSPI15446 can be a CFW load balancer with a large number of demand resources (see Figure 14). SRV_AP at 15113 can be a multi-homed backbone with huge capacity. Therefore, at the first perimeter, attacks can be caught, thereby protecting bandwidth in the GVN.

At the next perimeter 15M2, the FWDPI 15444 may pass all traffic through or just receive a copy of the traffic from the SRV_AP 15300 via 15T20 and may or may not return traffic via 15T22. The point is that the DPI feature can be a trailing edge indicator that allows specific traffic to pass but analyzes and logs the results. This FWDPI 15444 can also be a CFW that load balances with on-demand resources as needed to handle large-scale events when needed without making individual clients have to handle or incur the burden of maintaining Infrastructure cost burden.

Information from FWSPI 15446 and FWDPI 15444 are shared with each other via internal communication path 15P6, which may be transmitted by the NAPM of the GVN or through the GVN tunnel or through the GVN return tunnel or via other communication paths. Each FW mechanism also shares information with the central control server (SRV_CNTRL) 15200 of the GVN. This information can be relayed to other FWSPIs and FWDPIs around the world so that attack vectors, sources, payloads and other relevant information are available in the database so that SPI and DPI checks can have a reference point for comparison. This achieves increased efficiencies of scale because 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 clients.

The local FW15442 can be a standalone device, a software application (APP) running inside the EPD15100, or another type of FW device.

FffSPI15446 and FWDPI15444 devices and related equipment such as load balancers, cloud firewalls or other devices can be customized or can be provided off-the-shelf by other suppliers, so as to choose the best combination for the client. These devices must be able to receive and forward traffic, identify threats and most importantly communicate threat findings, and receive threat profiles and other information from other devices.

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

This can be achieved only by GVN's Secure Network Optimization (SNO) service 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, software and hardware may be distributed within the network equipment, and may be distributed across different circuit boards, processors, network interface cards, memory and memory devices.

One such network device is an endpoint device (EPD) 100. Another said network device 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 may be via encrypted tunnel SYSC04 to Point of Presence (POP) SYS406, through communication path SYS06 to WANSYS400 to communication path SYSCP10 to POPSYS402 to communication path SYSCP12. The path through the WANSYS 400 can also be through the regular unencrypted Internet.

Each device EPD100 and SRV_AP300 is also connected to SRV_CNTRL device 200 via communication path SYSCP08.

The software architectures of EPD100 and SRV_AP300 are very similar to each other, the difference is that each device plays a different role in operation and some modules are different.

The lowest level of each device is memory (RAM) 106 , 206 , 306 and processor (CPU) 102 , 202 , 302 and network interface (NIC) 108 , 208 , 308 . All of this is at the hardware level. The operating system (0/S) 110, 210, 310 may be a LINUX system or an equivalent system such as Debian or other systems. This operating system description includes packages and configuration for routing, hosting, communications, and other system-level operating software.

Above the operating system 110 , 210 , 310 there is a system software layer 112 , 212 , 312 of the Global Virtual Network (GVN's) operating system. Custom commands, system modules, managers, and other components operate here, along with other components of GVN. Each type of device in GVN can have some or all or different parts of these parts of the system software layer, depending on their role.

Database Modules Db 120, 220, 320 and Hosting Modules 122, 222, and 322 are configured in this example embodiment for GVN Neutral API Mechanism (NAPM), Graphical User Interface (GUI), and other server-side script hosting sites for listening, sending , processing, storage, retrieval, and other related base-level operations. The database 120, 220, 320 (013) modules may be MySQL or equivalents such as MariaDb and the hosting modules 122, 222 and 322 may 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.

Billing modules can collaborate and share information billed through the consumption model, such as the amount of data consumed by tunnel traffic. The accounting modules ACC132, 232, 332 operate on the EPD100 and the SRV_AP300 has a corresponding billing module. Both modules provide financial information to reporting screens, providing payment forms, emailed statements and other financial data generated by GVN.

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

EPD 100 has API module 130 , SRV_CNTRL has API module 230 and SRV_AP 300 has API module 330 . For simplicity of explaining this example embodiment, only one API module is described per device. In fact, depending on the function of the device in the GVN, the device can act as a combined client and server.

The Cache Manager on SRV_CNTRL 200 manages the primary index of multiple chained caches distributed across the GVN's many devices. Compression engine 136 on EPD 100 and compression engine 336 on SRV_AP 300 manage the compression and decompression of data stored on files, in 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 best exit point for the destination.

The remote retriever B0T311 on SRV_AP300 is the core component of the geographic destination mechanism (Geo_D).

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

The logging manager on the SRV_CNTRL 200 manages both local logging and logging shared by the device to the repository via API calls. The logging manager in this example embodiment is given the functionality to log operational events, API actions and transactions, and the logger also has other roles and processes for various aspects of GVN operation.

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

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

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

Located on the EPD 100 is a Content Delivery Agent (CDA) 158, which is a component of Geo-D. The SRV_AP 300 is provided with a content pulling agent (ContentPullingAgent, CPA) 358, which is also a component of Geo_D. The CPA358 works with the B0T311 on SRV_300 to pull content from the remote zone using the local DNS 354 seeded from that zone. CPA358 employs tunneling, caching, and other improvements of GVN to send crawled content to CDA158o

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

A connectivity manager (not shown) on EPD 100 and on SRV_AP 300 manages tunnels between devices and other device-to-device communication paths. The compression manager on 215 of SRV_CNTRL 200 manages local compression and also cooperates with compression engine 136 on EPD 100, compression engine 336 of SRV_AP 300 and compression engines on other devices of the GVN. Routing on EH) cooperates with ASR150, Geo-D and other elements to manage traffic routing.

The structure of the database tables in SDB100, SDB200 and SDB300 is equivalent for equipment operation, while the data of each database table is specific to equipment type, and each equipment has identification specific equipment. On SRV_CNTRL 200, repository database SDB 202 is used to store unique information for all devices, and repository management library 238 can use this information to communicate API credentials, tunnel information or other information to devices.

Each device stores the identity of the device itself and its peer-to-partner, API peer information, transaction list and queue data, and other information. The methods and databases have other uses than those described, but for simplicity of illustration this example covers only a few exemplary core functional elements.

topology

Figure 17 shows a GVN using a hub and spoke topology with backbone segments and octagonal routing. Figure 17 shows the network topology of the GVNs in two different regions 17-RGN-A and 17-RGN-B and how said regions are connected by the global connection 17-RGN-ALL via paths 17-POA and 17-POB. Furthermore, Figure 17 shows a hub-and-spoke connection in each of these two regions. Figure 17 is similar to Figure 15 with the addition of multiple entry and exit points (EIPs) in each region in the form of additional spokes of the hub and spoke model.

SRV_BBX17-280 and SRV_BBX17-282 are backbone switching servers and provide global connectivity. SRV_BBX may be one or more load balancing servers used as global links in 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. A central control server (SRV_CNTRL) 17-200 serves all devices in the region, and it may be one or more multi-master SRV_CNTRL servers. End point devices (EPD) 17-100 to 17-110 will connect with one or more SRV_AP servers through one or more multiple parallel tunnels.

This figure also shows multiple access points (EIPs) 17-EIP420, 17-EIP400, 17-EIP430, and 17-EIP410 in each zone as additional spokes of the hubandspoke model, which have communication Paths to and from the Open Internet. This topology can provide EPD connectivity to EIPs in remote regions through GVN. In the alternative, this topology also supports EPDs connecting to EIPs in the same region, to EPDs in the same region, or to EPDs in remote regions. These connections are optimized through GVN security.

Figure 18 shows the backbone connections between some GVN global nodes and their corresponding service areas in North America, Europe and Asia. As described in the legend box at the bottom right of Figure 18, each region indicated in this paper 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 points, the faster the information transfer.

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

The farther a querying 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 degrades QoS such that the device is no longer in the high performance zone and is now in the in the best service area.

If the QoS falls below a certain threshold, then the device is outside the best service area, and thus the distance between the device and the global node is so great that the advantages provided by the GVN, other than security, may be uncertain.

Figure 18 shows the district SJC18-01 of San Jose, California, USA, the district JFK18-02 of New York, New York, the United States, the district AMS18-11 of Amsterdam, the Netherlands, the district NRT18-21 of Tokyo, Japan, and the district HKG18-21 of the Hong Kong Special Administrative Region of China. twenty two. There are many other locations around the world where important global nodes need to be placed, but for ease of illustration, only a few locations are shown for illustration purposes.

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

Figure 19 shows the connectivity between the various devices within the GVN, where multiple connection paths are indicated from the devices in the spokes to the central device. SRV_BBX (Backbone Exchange Server) 19-800 and 19-810 points are placed based on the client's location with respect to the best Internet Data Center (IDC) for the pipeline, interconnection, to serve the target area, while via route 19 -BB2 and 19-BB6 connect global positions.

SRV_BBX is used as the center of the area it serves. The hub passes over a top-of-the-top (OTT) tunnel over Ethernet links in the Internet, a tunnel over direct Ethernet links, InfiniBand over fiber optics, InfiniBand over Ethernet, or other Connectivity of forms to connect to each other. Each hub serves multiple SRV_AP servers, for example 19-302, 19-306, 19-308 serving a zone within the global zone. 31^_4? 19-312, 19-316 and 19-318 can Serving another zone from the global zone.

End point devices (EPDs) such as 19-100 to 19-128 will connect with the most appropriate SRV_AP server with respect to their location, network connectivity, peer-to-peer and other relevant factors. These factors are constantly changing, and thus multiple tunnels to multiple SRV_AP servers are always maintained by Ero. Each Ero is connected with various (one or more) SRV_AP servers at the same time.

There are egress points (EIPs) at the EPD, SRV_AP, and other locations where traffic can leave the GVN for 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_AP19-308 and SRV_AP19-318 are also connected to each other through a tunnel path such as 19P60 so that two EPDs such as EPD19-110 can be connected with EPD19-128 via paths 19P22 to 19P60 to 19P58.

A central control server (SRV_CNTRL) 19-200 is linked to a plurality of devices, for example via path 19P62 to SRV_AP 19-302, for Neutral API Mechanism (NAPIM) information exchange. EPD is also connected with SRV_CNTRL19-200 via NAPM path. To keep this example embodiment relatively simple, the NAPIMEH) to SRV_CNTRL path is not shown.

NAPM information exchanged between 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 share other information to achieve automatic and safe operation.

Figure 20 shows how the GVN module interacts with the device. A Global Virtual Network (GVN) consists of various devices operating independently as well as in cooperation with other devices. Although the role of each may differ based on their type and underlying functionality, they follow similar code bases, database schemas, and other architectural elements.

Infrastructure is installed in an area to support the operation of EPD and PEPD. Devices such as Endpoint Device (EPD) 100 , Portable Endpoint Device (PEPD) and Endpoint Hub (EPH) connect various LANs, PANs and other networks to the GVN via tunnels to Access Point Server (SRV_AP) 300 . Each device has its own locally hosted database.

Redundancy is provided by having multiple primary SRV_CNTRLs and multiple servers of each type in each region of other server types. The central data repository is located on the central control server (SRV_CNTRL) 200 . The job of SRV_CNTRL is to connect to various devices via GVN's neutral API mechanism. API calls via GVN's NAPIM allow API peers via Device_10 and Registry/Zone Mapping in the Db repository on SOPC^JRVJ^NTRL via the path used for inter-device communication eg EPD100 to SRV_BC20-502 communication For relationship management, generate appropriate Server Availability Lists (SALs) and accept logging. This enables effective management of relationships and connections with SRV_AP and GW servers.

GVN's backend servers and infrastructure equipment include Back Channel Server (SRV_BC) 20-502; Secure Boot Server (SRV_SB) 20-504; Authentication, Authorization, Accounting Server (SRV_AAA) 20-508 and Logging Server (SRV_LOG )20-516 and so on.

Gateway servers and other devices are connected to SRV_CNTRL 200 via connector 20AD0 and to gateway devices via "All Devices" center 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 for third party connections (SRV_GW_TPC) as a class of other SRV_GW_* 20-512 server.

A gateway server that plays a special role can be adapted to this function and the way it is protected. By authorizing the email gateway server, it can be set as a secure email sender and receiver. This will require configuration and maintenance and observation of its operation. At the same time, however, no additional servers are required to handle email, freeing those devices from the administrative burden. All devices can forward emails via the data payload sent to the API by the action call requesting to send emails. Flags in the payload can indicate whether the email should be sent immediately or at a specific time, or with what priority it should be sent. Other settings can govern how it is sent. SRV_GW_EMAIL will receive these data payloads, add them to its email sending 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.

Logging servers and other devices can also be accessed by the GVN device via 20AD4.

Figure 21 shows additional details on how the GVN module interacts with the device. These additional details include communication paths, such as 21Q00 from SRV_BC4-502 to 31^_0 stage 200, for reporting information from the back channel server to the central control server. The 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 to the SRV_CNTRL 200 and/or other devices can provide a holistic view of the larger system. A constant feedback loop allows for automatic adjustment and learning on the fly for 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 external paths (PE), tunnel paths (for traffic) (PT), control paths (CP), encryption system paths (ES) and API communication paths (PA) between GVN devices and more Multiple communication paths.

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

An Advanced Smart Route (ASR) within the EPD can route local traffic via the route 22-PE00 to the Point of Presence (POP) 22-020 to 22-PE02, to the nearest Internet 22-010. The back channel server (SRV_BC) 22-502 is connected to the EPD 100JS via a back channel connection from 22ES04 through 22-010 into the EPD 100 via 22ES02 to 201 to 22ES020.

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

The figure is not drawn to scale, but for example SRV_AP22-302 and SRV_AP300 are in the same area, and via route 22PE04 to POP22-022 to 22PE08 to Internet 22-012 and route 22PE16 to Internet 22-012 via POP22-026 to 22PE12, from GVN leaves and enters Internet 22-012<^ ^TM all can carry out local DNS lookup to domain name service (DNS) server 22-402.

Both SRV_AP22-302 and SRV_AP300 maintain API communication paths to SRV_CNTRL200 via 22PA02 and 22PA08 respectively.

Gateway device (SRV_GW) 22-514 is located in the same area as SRV_AP 22-302 and SRV_AP 300. This may send emails, handle financial transactions and other functionality of the GVN's SRV_GW device.

SRV_AP22-306 is connected to SRV_CNTRL200 via 22PA10, and the exit point to Internet 22-014 in its area is via 22PE20 to POP22-024 to 22PE22 to Internet 22-014.

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

SRV_AP22-304 is connected to SRV_CNTRL200 via 22PA18, and the exit point to Internet 22-016 in its area is via 22PE26 to POP22-028 to 22PA30 to Internet 22-016.

SRVGW 22-512 is connected to SRV_CNTRL via 22PA14 and to SRV_AP via 22PA16. Local traffic from SRV_GW22-516 leaves via 22PE28 to POP22-208 to 22PA30 to Internet 22-016.

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

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

Figure 23 shows multiple tunnel connectivity between End Point Devices (EPD) 100, 23_102, 23_158 and Access Point Servers (SRV_AP) 300, 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 Back Channel Management Servers (SRV_BC) 23-502 to other devices in the GVN.

SRV_BC23-502 establishes and maintains backchannel tunnels 23PA02 to EPD100, 23P018 to EPD102, 23PA06 to EPD23_158, 23TP50 to SRV_AP23-302, and so on. There may be more SRV_BC servers within the GVN to provide redundancy in case one SRV_BC is not operating, and also to ensure optimal performance by placing SRV_BC servers in strategic locations close to the devices they are connected to.

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

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

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

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

Another benefit realized by the GVN is to provide a secure tunnel connection with the EPD 23-158 at the location of the service providing partner organization in the cloud, so as to enable access via the GVN to their servers and the A secure tunnel for related services.

LAN-WAN-LAN bridge from LAN 23-002 to LAN23-012 can be via from 23-002 to 23CP02 to GWD23-004 to 23CP04 to EPD100 to 23TP0023TP0223TP04 to SRV_AP300 to 23TP1023TP1223TP14 to SRV_AP23-302 to 23TP2223TP4223TP4223 Communication path from 23CP14 to GWD23-014 to 23CP12 to LAN23-012. All traffic carried by this bridge is protected and improved by the GVN mechanism.

Multiple tunnels between two devices such as 23TP0023TP0223TP04 or 23TP1023TP1223TP14 or 23TP2023TP2223Tp24 can provide a single communication path by sending traffic along one tunnel, or two or more tunnels can be aggregated, where two or more A bonded tunnel can pass traffic as if it were a single tunnel.

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

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

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

A0 represents a 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 in order to link them to the Internet. This hop and hub-and-spoke structure shows network clustering within the wider ISP network. A line with a circle in the form of a wire cap indicates this connectivity. For simplicity, in this example embodiment, the structure of A1, A2, A3 and other POPs does not show the links of 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) enabling Internet connectivity via the POP.

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

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

1X1 and 1X2 are examples of Internet Exchanges (IX), which may be independently linked to each other via backbone or backbone-dedicated connections. IX is that ISPs and other ISPs can connect to each other in a "meet-meroom" or equivalent arrangement for direct network-to-network peering.

There are also communication paths between the ISP's network and other ISP's networks, or IXs or intermediate routers between them. These backbone communication paths are shown by lines with arrow caps at both ends. Intermediate devices are shown by circles between arrow-capped lines. Backhaul connectivity between IXs is shown by dashed lines with arrow caps at both ends. Page connector IBH1 is used to show International Backhaul (IBH), ie 1X2 also has connectivity to another IX not shown in this example embodiment.

To illustrate a 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 should be the most efficient route.

To illustrate the detour path due to path failure, if path GX1-1 fails, traffic from H0 or A0 destined for G0 will not be able to pass through GX1-1 via 1X1. An alternative is for traffic to go to G0 via B0 and E0. In the past, only 4 intermediate jumps were required from A0 via AXl-l->AXl-2->IX1->GX1-1, now more jumps are required AX1-1 to AX1-2 to 1X1 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 G0. If GX101 fails, traffic now traveling from A0 to G0 requires 17 intermediate hops and a correspondingly higher latency.

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

This extra traffic can drain the connection and can cause higher latency and congestion-related packet loss. Peering through IX will generally have much more capacity and capability to handle large volumes of traffic. When the single intermediate hop GX1-1 from G0 to 1X1 is not available, the extra hops (TTL) and round-trip delay (RTT) through the alternate route can lead to too many hops or too long a packet to be marked as non-deliverable or Internet-based services timed out.

Optimal connectivity between two ISP networks via IX and by employing backhaul is route H2 to H0 to HX1-1 to HX1-2 to 1X1 to X1X2-1 to X1X2-2 to IX-2 to DX2-2 to DX2-1 to D0 to D2 are indicated. Thus, a total of 12 jumps from POP to POP.

The next direct path should be via B0, 16 hops in total. The path is H2 to H0 to HX1-1 to HX1-2 to 1X1 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 will be via A0 via C0, 19 hops in total. The route is H2 to H0 to HX1-1 to HX1-2 to IH to AH-2 to AH-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 peering relationships, an indirect but possible path could be 30 hops, eg via G9 via E0 via B0 via F0. The route is H2 to H0 to HX1-1 to HX1-2 to 1X1 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 R) 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 because of poor or incorrect routing policies governing intermediate devices between origin and destination. For example, if traffic from C0 is expected to be routed to G0, since C0 may think that B0 and E0 are close to each other and that this is the best path, C0 will choose to go to B0 when it thinks B0 will send traffic to E0. However, B0 may not directly peer with E0, but have a strong peer relationship with F0. F0 also doesn't have a peering relationship or a path to E0, and so it might send traffic to D (LD0 only has two choices of sending traffic to C0 or to B0, in both cases the end result is traffic Loops, non-transitive. There are other causes of such loops, such as routing table failures, compromised devices, intrusions and other misbehavior, or other causes.

The end result of too many hops and too high a delay time is a timeout or packet being dropped.

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

At IX1_IDC, B5 and IX2-IDC and possibly at D5 in order to include alternative routing options and failover, the SRV_AP server installed and operating will provide peering with all other networks and bypass any broken paths by providing Perform routing selection to provide a stable path between SRV_APs. This strategic positioning provides the flexibility and possibility to implement other performance enhancements.

Figure 26 shows how GVN can incorporate techniques such as Network Slingshot to achieve many benefits seamlessly across distances. Network Slingshot is further described in US provisional patent US62/266,060.

The first boundary is GVNEIP26-322 between the Internet and GVN. The next boundary is Security Perimeter 26-182. This layered approach to security protects the core infrastructure on which GVN is built.

A security 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 top of the Open Internet (OTT) via secure GVN tunnels. Under the security perimeter 26-182, GVN connections employ various protocols over dark fiber or other connections not directly reachable from the Internet.

A supercomputer node 26-538 may operate within (beneath) a secure perimeter 26-832 operable with advanced features such as remote direct memory access ( RDMA) real internal network.

Figure 27 shows how the tables on the databases of the various GVN devices relate to each other and how they interact. For example, the repository database DB_2300 on SRV_CNTRL has various tables on devices and interactions between devices via GVN's Neutral API Mechanism (NAPIM). Tables in database DB_2300 such as device registry DBT_2310 are designated as REP0_ACTIVE, which means that the table receives information from many sources, is read/written and can be queried as an information source for selectively or fully For example, the device identifier DBT_2102 is replicated as part of the database EH) local DbDB_2100. This table DBT_2101 has the identity SEL_REP+W, which allows selective copying from DBT_2310 and reporting of the relevant identity to the device registry.

The control and release of information is governed by the data manager. Database table type indicators include normal read/write table "regular" (REGULAR), read-only replicated table REP_INF0, read-only partially replicated table with only relevant rows SEL_REPSEL_REP, from repositories such as device registry DBT_2310 Merge table REP0S_ACTIVE for all sources. Other possibilities include LOGGING from source tables to be merged on database DB2800 on SRV_LOGS. These identifications of tables are for example purposes only and may vary in real-world usage, and there are more tables and other types based on usage.

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

There are 3 layers in GVN, and layer 1 is the physical network layer on which GVN is established (OTT), such as the Internet. Layer 3 is the GVN network layer that is viewed by client devices as a partial or complete path to a destination. Layer 2 is the logical layer between the two.

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

As another example, to operate NAPIMG 102, an API Listener and Handler HL 102 is required on the host server. Operations Manager OM 102 is running on both the host client and the host server in AAPIM to handle the preparation of API requests and responses before sending , disposal, processing. The dynamic configuration of NAPIM requires the peer management PM 102, the relevant NAPIM action management AM 102, and transactions at the physical TP 102 and dynamic TM 102.

structure

Figure 29 shows the Advanced Smart Routing (ASR) feature of GVN. Specifically, the figure shows the Advanced Smart Routing (ASR) feature of the GVN within the End Point Device (EPD) 103 for multiple paths to exit 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 GVN tunneling will not necessarily result in a performance increase; 2) Local traffic is carried to the Internet 203 in encrypted tunnel TUN1; 3) Traffic destined for another area goes via TUN2 to SRV_AP 301 in that area to access Internet 303; and 4) Traffic goes via TUN3 to other remote areas where there are some ASRs 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. ETH0103-9 is the WAN port of the Network Access Point (NAP) that connects the EPD 103 to the Internet via the P401 of the POP 401 leading to the Internet 402 of the ISP. All traffic from EH) will pass through this connection as the first layer of the GVN network. The TUN tunnel on top of this connection is the third layer of GVN. ETH1103-1 is a local area network (LAN) port connected to LANA102 via path P102. ETH2 103-2 is another physical LAN port connected to LANB104 via path P104. Finally, there is a virtual interface (VIF) acting as bridge BR0 103-3 for communicating with LAN interfaces 103-1 and 103-2 via internal paths DPI and DP2 respectively.

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

For example, at VIF0103-5, local traffic leaves via P401. All other traffic through VIF0 103-5 is sent via DP5 to the next VIF in the chain, ie, VIF1 103-6. The traffic from VIF1103-6 destined for Internet 203 leaves from EPD103 via path P201, reaches SRV_AP201 through encrypted tunnel TUN1, and then reaches path P202 to POP202 to P203 and then to Internet 203. From this location, a zone DNS lookup can be queried via SRV_DNS 204 via path P204. It can be connected to host client 205 or host server 206 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 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 Internet 303 and to others outside the Internet place.

Any additional remaining traffic from VIF2103-7 will be sent to VIF3103-8. All traffic from VIF3103-8 is sent to SRV_AP501 via encrypted tunnel TUN3. ASR routing is applied at SRV_AP 501 so that traffic destined for an IP address within Internet 503 is sent to POP 502 via path P502 to Internet 503 .

The traffic from SRV_AP501 destined for the Internet 603 is sent to SRV_AP601 through the connected encrypted tunnel TUN4 to the path P602 to POP602 to P603 to the Internet 603, and reaches other places outside the Internet.

A DNS lookup in the area of the Internet 603 can be done to SRV_DNS 604 and can connect to devices at that location, eg, via a P 605 to a host server 605 or other device.

This ASR mechanism can be used at various traffic nodes in order to optimally send traffic to the best exit point traffic on the Internet located in multiple target areas, thus enabling geographic destination traffic and gaining the benefits achieved by GVN Other advantages.

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

The first step is to open the 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 presents the certificate to S for S to use, along with the required security information, to establish a Secure Sockets Layer (SSL) connection 30-8 between the two. Compare the certificate received from C with the corresponding certificate key on S. If the certificate is expired or incorrect, then the SSL connection cannot be established and the process will stop.

This connection will be used to send information 30-10 from C to S about the tunnel, including passphrases, metrics, and other information about the tunnel metrics, including which IP address and port each device will use for tunnel traffic, and other information.

S will verify this information 30-12 against its own version of the tunnel metric and passphrase, among other information. If the information is not accurate, then 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 30-14 of initiating or building a tunnel with the provided configuration settings.

After tunnel establishment, route 30-16 may be applied at C or S or both. Although the tunnel is established, during the process of adding routes to it, traffic may not be able to flow through the tunnel, or even if traffic can flow through the tunnel, there is a risk of data leakage. This risk occurs because traffic destined for a destination IP address can leave the default egress path to the Internet without being encrypted or traveling through a tunnel before all routes are applied. After the route has been added to the tunnel, subsequent traffic will be protected as it will be routed through the tunnel. Depending on the size of the routing table to be applied to the tunnel, this delay can be a considerable amount of time.

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

Figure 31 shows the information flow required by the two peers in a peer pair. The peers can be client (C) and server (B), or one peer to another in a P-2-P topology. To simplify notation and description in this exemplary embodiment, C to S and P-2-P represent two peer relationships of the same type, and the C to S relationship is described herein. GVN mainly uses the C-to-S relationship between devices, but its methods and techniques can also be applied to P-2-P peer pairs for tunnel construction.

An encrypted tunnel is essentially a secure communication path through which data can flow. Encrypted tunnels are ideal for securely exchanging data when the client and server are separated by a certain distance and the connection between them is over the open, unencrypted Internet. If there are human network administrators at either end, they can program the device. However, there are challenges with how to relay secure information such as passphrases, keys, and other information. Some can use voice calls to coordinate, others can use a series of posts to share information through a secure website, or other methods can be used. It may be necessary to perform the task of manually setting up individual tunnels. Managing multiple tunnels can become cumbersome.

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

SRV_CNTRL31D00 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 for evaluating certain data to generate informative reports.

The client device 31D02 represents the device that will initiate tunnel building by "dial-up" connecting to the server device via a specific IP address and port. Many client 32D02 devices can use similar software and configuration to connect to GVN at the same time, and the distinguishing factors between devices are the unique device identification UUID, and the unique information of each client and each channel.

Server device 31D06 represents a device that will listen for client connection attempts on a specific IP address and port. If the client follows the correct protocol and establishment 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 can be connected to GVN at the same time with similar software and configuration, and the distinguishing factors are the unique device identification UUID and unique information.

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

Some information is equivalent between C and S, such as the passphrase that one will present to the other, other information will vary depending on availability. Information requirements for building 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 for its operation; Keys, passphrases, and other information about the security protections used by the tunnel; SSL certificates and other information used to secure the exchange of information prior to tunnel establishment; and other information. This information is shared between devices using specific API action calls of GVN's neutral API.

Pre-Tunnel 31S0 describes the process of receiving and sharing information between Device 31D0231D06 and Repository 31D00 on SRV_CNTRL and returning it to Device 31D0231D06. The API communication paths API-31CP0, API-31CP2, API-31CP4, and API-31CP6 represent request-response information exchanges, and the arrows indicate the direction of information flow from one device to another.

The server 31D06 reports the information to the receive information 31C-0 module of the SRV_CNTRL 31D00 device via the path API-31C0. SRV_CNTRL31D00 receives information from the server and stores the relevant identity, tunnel, current payload and other information in its repository. For example, algorithms and AI logic on SRV_CNTRL31D00 analyze server load, and based on current and expected demand from client 31D02 devices, updates to server availability C-1 matrix are made. Server Availability C-1 information can be transmitted by: Shared Information 31C-6 module copying database to client 31D02 via API call path API-31CP6 via GVN's API; direct file sharing via GVN; or other methods.

The client 31D02 reports the information to the receiving information 31C-0 module of the SRV_CNTRL 31D00 device via the path API-31CP2. This information will be stored in the memory bank of SRV_CNTRL31D00. Specific tunnel information from the client 31D02 can be shared by the shared information 31C-6 module with the server 31D04 via the gAPI-31CP4.

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

If the client 31D02 or the server 31D06 detects that there is a problem establishing a tunnel with 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 of the peer pair via shared information 31C-6, where client 31D02 information is sent via API-31CP4 and server D02 information is 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 collate, secure and coordinate its list of clients 31C-4 that will attempt to establish new tunnels for the shared resources of the server 31D06. This information will be fluid and needs to be updated periodically via secure API calls to SRV_CNTRL31D00.

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

The stage of tunnel construction 31S4 describes the process of tunnel establishment 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 a 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 refer to threats to information exchange 31C-10 during tunnel establishment. If the signature of the tunnel type is visible, there may be threats during tunnel establishment 31CC-8, such as a fake Transport Layer Security (TLS) handshake from an intermediary illegal operator, TLS errors in the handshake, blocking or blocked ports and IP identification, timeouts caused by filtering devices, reset packets sent by intermediate ISPs or firewalls or devices, or other threats.

If the information exchange 31C-10 is successful, then the Build Tunnel 31C-12 step is performed, where routing and other related operations will be applied to enable the secure construction of a tunnel TUN between the client 31D02 and the server 31D06.

Tunnel Setup 31S6 describes the phase during normal traffic flow through the tunnel. Information must be communicated between the devices, and SRV_CNTRLD00 is required to manage unique information for the various client 31D02 and server 31D06 devices, as well as unique information for the multiple tunnels built between them.

The exchange of information between devices has to happen regularly, because often new dynamic tunnels need to be formed. Some ports on an IP address may be blocked or become blocked, and simply changing the port on that IP address will allow tunneling and data to flow. Furthermore, each tunnel requires one or more unique ports per IP address in order to avoid collisions between tunnels. When the client 31D02 device requests to create new tunnel information, a random port number is generated and the port availability for that particular IP address on the target server 31D06 is checked against two or more of the following factors: whether the port is already used by an existing Tunnel usage (operational port or alternate port that can enter operational state); and whether the port has been used by a particular client 31D02/server 31D06 peer pair in the past and has been blocked. In both cases, new random numbers will be generated. There are 65,536 ports available per IP address, of which a certain number is reserved for specific services. For example a lower limit value of 5,500 will leave 60,036 available ports that can be used by a random number generator with a minimum value of 5001 and a maximum value of 65536. When the tunnel is torn down and the port is marked as blocked for one peer pair, it becomes available for other peer pairs. This port release is necessary in order to avoid port exhaustion. Therefore, SRV_CNTRL31D00's tracking of IP and port combinations is necessary.

Tunneling can go through steps to help its own establishment, but this has limitations. Although secure, most tunnels are visible during establishment. Both the handshake and the signature on the type of tunnel are visible during operation. Manually setting keys is cumbersome and doesn't change often, and there is an increased risk of them being corrupted if used over time; therefore, keys should be replaced frequently with new ones.

An automated system needs to ensure that information such as new keys, ports for IP addresses and other information can be created and made available to both parties of the peer pair to enable the construction and re-establishment of tunnels. Both parties must be configured and ready to be able to establish the tunnel. Therefore, the information exchange between peer pairs needs to be secure, otherwise the security integrity of the tunnel itself will be destroyed.

While the tunnel is established and 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 poses the risk that the packet flow is captured and the tunnel content is decrypted using brute force key cracking. The reset signal may break the tunnel if the reset code or other tunnel control code is known. Therefore, in order to maintain the security and integrity of the tunnel between the client 31D02 and server 31D06 devices in the peer pair, it is necessary to update and share information automatically and securely.

The GVN structure enables devices to automatically and securely establish tunnels between peer pairs based on recent information. A combination of security features and methods provide self-reinforcing protection.

Figures 32-35 illustrate GVN's third layer of neutrality and security relative to GVN tunnels, while comparing hop counts to those of the underlying Internet connection. The use of the term LAN in these figures is generally intentional and may refer to a network of a home or office or an Internet Data Center (IDC). A device can be a client or a server connected to a LAN. Figure 32 shows the GVN tunnel from LAN to EPD to SRV_AP to Internet. Figure 33 shows a GVN tunnel from LAN to EH) to SRV_AP to IjEro to LAN. Figure 34 shows a GVN tunnel from LAN to EPD to SRV_AP to SRV_AP to EH) to LAN. FIG. 35 shows additional elements of the GVN tunnel from LAN to EH) to SRV_AP to SRV_AP to EH) to LAN of FIG. 34, including peers.

All four figures include common baseline elements from EH1 to EH17, which represent external hops in underlying Internet connectivity. The distance between each jump is not to scale and does not indicate anything other than the number of jumps. Other common elements include a local area network LAN1 with 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 the access point server AP-1. Tunnels exist between these devices, and each device NH1 and NH2 within the third layer of GVN has a neutral hop.

Figure 32 shows the GVN tunnel from LAN to EPD to SRV_AP to Internet. The tunnel can also function in the other direction, providing ingress 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 this LAN o

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

A tunnel exists between EPD-1 and AP-1. This is coupled to a second tunnel between AP-1 and EPD-2. In contrast to the 13 hops on the basic Internet between H13 and H115, there are three neutral hops represented by NH1, NH2 and NH3 within the third layer of the GVN.

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.

Figure 34 shows a GVN tunnel from LAN to EPD to SRV_AP to SRV_AP to EPD to LAN. This variant shows an end-to-end GVN tunnel between the edges of two LANs via two (or possibly more) SRV_APs. The difference between this variant and FIG. 33 is that a second AP-2 is inserted into the path to represent another linkage of tunnel AP-1 to AP-2 and tunnel AP-2 to EPD-2. Adding another internal neutral hop brings the hop count within the third layer 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 Era to LAN of Figure 34, which includes a peering point that peers between the ISP and the edge of the network. This variant shows an end-to-end GVN tunnel between the edges of the two LANs via two SRV_APs, and also further shows about carrying traffic between EH-3 and EH-15 over some part of the Internet Different Internet Service Providers (ISPs) for more information.

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

Certain advantages can be realized by placing SRV_AP_1 at PP-1 so that this SRV_AP is directly peerable with both ISP-1 and ISP-2. Further advantages can be realized by placing SRV_AP-2 on PP-2 to make this SRV_AP directly peerable with both ISP-2 and ISP-3. If ISP-2's network is less than ideal, traffic may alternatively be routed by the GVN bypassing ISP-2 through another route or line or ISP or carrier.

The hop count through the neutral third layer of the GVN remains at eight as in FIG. 34 . Distances between ISPs are not to scale. Also, there may be many more hops within the ISP's network, but the numbers shown have been simplified for simplicity.

While Figures 33, 34 and 35 all show the joining of tunnels at AP hops, this is considered a single tunnel for client devices within LAN1 and LAN2. This single tunnel represents GVN's neutral third layer, within which all traffic that would normally travel on the Internet can run, including TCP, UDP and other protocols, in addition to other tunnels such as IPSeC, OpenVPN, PPTP and so on. The third layer of GVN also realizes other advantages. Some advantages include a lower TTL and the ability to have more control over routing, but there are others as well.

Figure 35 illustrates weaving together various network structures into a network blanket framework. This example embodiment shows the weaving together of various network structures at the physical layer, with a global virtual network (GVN) operating above the physical layer (OTT). These structures at the physical layer 36102 constitute a series of network segments which may, for example, be IPv4 and IPv6 aware, or just one or the other protocol. End Point Device (EPD) 36100 to LAN (36000) can be IPv4 and/or IPv6. Tunnel TUN36P2 can be one or the other protocol or both protocols between EPD36100 and Access Point Server (SRV_AP) 36300.

Exit/Entry Points (EIP) 36302 indicate exit and entry points from the GVN to the network fabric at the Internet level. Path 36P04 indicates a connection to IPv4 Internet Network 36400 and Path 36P06 indicates a connection to IPv6 Internet Network 36600 .

The key point is that the blanket framework of GVN allows end-to-end linking of structures such as IPv4 Internet 36408 to IPv4 in LAN 3600 or end-to-end IPv6 3608 from Internet 36600 to LAN 36000 even though there may be some different segments on the physical level 36102 in this way.

Fig. 37 shows the communication paths for automation device cooperation in GVN. This example embodiment shows the communication pathway used by the Neutral API Mechanism (NAPIM) API372023720637208 to enable automated interaction 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, connections, testing and diagnostics, and other functions.

Infrastructure operations such as predictably updating device operating system software and data packages from trusted sources, maintaining GVN modules and databases, and others. For example, End Point Device (EPD) 100 may query Central Control Server (SRV_CNTRL) 200 via API 37202 along path P37202-B to 37202-C. In another example, Email Portal Server (SRV_GW_Email) 37310 may update system packages from SRV_CNTRL 200, which is a trusted source of system software.

Others running via daemon or other recurring operations such as heartbeat functionality include keeping services up, running by reporting to SRV_CNTRL 200 from devices such as Access Point Server (SRV_AP) 300 via API 37202 via path P37202-A to P37202-C and healthy. There are also redundant paths such as via API 37208 through path P37208-A to P37208-C. Other heartbeat functions can keep queues running and flush them out, can replicate logging data, and can do other such things.

For a connection (such as tunnel P37206-C between EPD100 and SRV_AP300), the listener at SPSRV_AP300 and initiator EPD100 at both ends of the tunnel require relevant information. This information may include peer pair information associated with each device or associated with the tunnel. Both communicate with SRV_CNTRL200 via separate paths via API37202.

With multiple tunnels attached to virtual interfaces and options for more than one tunnel between devices (such as between EPD100 to SRV_AP200 or SRV_AP200 to SRV_AP20x), various API calls are required to manage multiple tunnels, routing, and more information.

The power server availability algorithm relies on systematic analysis of various information to provide EPDs with a list of SRV_AP servers to which they can tunnel. Since each tunnel requires an IP address and port at either end mapped to the GVN fabric for routing clarity, changing information needs to be updated. Automated equipment collaboration helps with this.

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

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

System and resource monitoring and reporting are also critical to automatically conveying information about services being up and running, hosts working, database engines up and running, security systems running, and more.

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

Depending on the device type, a newly created device could load a copy of the master disk to be configured during first boot, or as in the case of a remote server, a first boot script would be securely transferred to the server to run to pull the essential system files. Other possible scenarios could combine the combination of preloaded files with files to be loaded remotely.

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

Data applicable to device 38D-00 is sent via path 38P16 to database 38D-04 according to the device type and the device's Universally Unique Identifier (UUID). Some information may also be populated into a template configuration file that can be cloned to the software and configuration file storage 38D-02 on the device 38D-00. Identification information that is unique to a device may include: device attributes, naming and UUID information, credentials/keys, key regulators, other information.

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

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

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

Figure 39 shows bridging two LANs into a Wide Area Network (WAN) via two or more EHs. More specifically, this figure shows bridging two LANs 39-000 and 39-010 into a Wide Area Network (WAN) via ETO. Each EPD first connects to the access point server SRV_AP39-200 via a base station tunnel established over its Internet connection.

From EPD 39-100, base station connectivity path OTT is via path 39-P002 to Point of Presence (POP) 39-002 to Internet 39-004 to POP 39-006 of SRV_AP 39-200. From EPD 39-110, base station connectivity path OTT is POP 39-016 via path 39-P012 to Point of Presence (POP) 39-012 to Internet 39-014 to SRV_AP 39-200.

The transmission path 39-P06 from POP39-006 to POP39-016 may be a path through the Internet by passing through 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 do not control the GVN or EPD.

EPD39-100 establishes tunnel TUN39-P10 between itself and SRV_AP39-200. EPD39-102 also establishes tunnel TUN39-P12 between itself and SRV_AP39-200. One or both of these tunnels may or may not be encrypted or secured. There may also be another tunnel, the inner tunnel INTTUN39-P20, which passes through two other tunnels, joined at SRV_AP39-200 through which traffic can flow. This tunnel can be a communication path to establish a WAN.

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

Figure 40 shows the multi-perimeter mechanism (MPFWM) running on the GVN. This example shows how there can be a second level 40T0P88 above the elements (OTT) in the Global Virtual Network (GVN). At first stage OTT 40T0P86, GVN 40-86 operates OTT, Base Station Internet Connectivity 40-82. In the case of a multi-perimeter firewall mechanism 40-88 configuration, the GVN operates OTT and thus can be configured as a second level 40T0P88 above the top element.

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

The blanket framework 41-500 weaves together the various network protocols of the individual network segments as well as end-to-end protocols, which may be "through" the GVN path.

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

GVN Global Network OTT Internet+ via other links 41-700 is GVN layer 2 logic where things like Geo Destination, DNS Management, Advanced Smart Routing (ASR)/Global ASR (GASR), Server Availability, Tunnel Management and Builder Module operations for modules, etc.

GVN41-800 represents the network seen by client users.

Figure 42 compares Internet Protocol IP stack B2, OSI model C2 and GVN stack C3.

The IP stack consists of network interface T1, Internet T2, transport T3 and application T4.

For non-GVN traffic and for a physical tunnel invisible to the client egressing through ETHNICN1, the IP stack seen by the client follows element R1 at network interface T1 layer, element R2A at Internet T2 layer, transport T3 Element R3A or R3B at layer and element R4A, R4B or R4C at application T4 layer.

For the traffic passing through the GVN tunnel and network, the client will 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 R7B at the application T4 layer R7C observes its GVN traffic.

While the OSI model may be used by clients for tunneled IP traffic, GVN has its own stack of Network Interface G1, Internet G2, Transport G3, GVN Routing and Logic G4, GVN Internet G5, GVN Transport G6, and Application G7.

logic

Figure 43 shows 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.

The Internets of countries in regions such as Asia are mainly connected to each other by terrestrial and submerged marine links. Usually they are linked somewhere in a third or other country in the middle of the traffic transmission from one country to another.

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

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

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

Once in the destination area, the traffic will land from the transatlantic link 43P600 in one country eg in UK43-600. From UK43-600, traffic will travel via link 43-600 to France 43-602 and then via link 43P606 to Germany 43-606. Such extra in-region jumps can add 30ms to more ms to the RTT depending on the destination.

International backhaul quality can also vary between peers, each with various RTTQoS times. Routing and corresponding speeds on the normal Internet are determined by intermediary actors, and these are in most cases based on the lowest cost usually delivering slow RTT speeds. High latency isn't the only problem lower-quality networks have to contend with. These generally have higher congestion levels and correspondingly high packet loss. Lost 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 TCP/IP stack B2, the Open Systems Interconnection model (OSI) A2C2, and variations such as the TCP/IP model in GVN stack A3, and models of GVNC3.

Two angles are presented. Client angle A1 compares A2 and A3 side by side. The global virtual model framework C1 compares C2 with C3. There is also a tree-connected layer of B2.

In the TCP/IP model B2, there is a network interface T1 corresponding to the Ethernet protocol R1. Internet T2 corresponds to Internet Protocol (IP) R2. The transport T3 layer 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, where the hypertext transfer protocol HTTPR4A, mail service P0P3R4B and GVN applications exist. Other applications such as File Transfer Protocol (FTP) or other services may exist in this layer.

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

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

An extension to the network tree on top of R4C is built through the TCP/IP model of GVNB3.

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

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

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

The application layer of T8 corresponds to Internet protocols such as FTPR7A, HTTPR7B, and POP3 from the perspective of the client. The OSI model splits the application layer T8 into three layers, Session S5, Presentation S6 and Application S7.

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

There is a similarity between the network operation in the third layer of GVN and the first layer.

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

Figure 45 shows a tunnel between two LANs via a GVN. In particular, this figure depicts the internal path from LAN 45-000 to LAN 45-002 via GVN paths 45P00 to 45P10, the segment via internal tunnel 45L300. There are five hops 45H0 to 45H8 visible to clients in either direction between the two LANs. The path through the 45L300 is the GVN layer visible to the client.

The GVN1-level network layer 45L100 represents the end-to-end physical network layer 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 inner 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 the tunnel, just like 45-104 for IPv4 segments, then 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 via paths P01 to P13 with the network via GVNT01 to T03 at the base station level.

A large number of measurements at base station Internet level CTN140 are LAN to GVN via EPD46-100 to SRV_AP46-300, for which connectivity metrics of bandwidth BW, delay time At=Ams, packet loss and other factors are evaluated. At the other end of the connection, similar measurements at CTN 142 of BW, At=Cms, packet loss and other factors measure the rise in traffic from EPD 46-102 into the GVN. With GVN between SRV_AP 46-300 and SRV_AP 46-302, various Internet segments CTN 340 measured BW, At=Bms, packet loss, and evaluated other factors for GVN cross-region OTT. The total path delay time through the GVN layer three GVN4-3 can be calculated as the sum A+B+C of the delay time, all in milliseconds.

In GVN Layer 3 GVN4-3, ASR and other features dictate how and where traffic flows through the GVN. This requires determining the best tunnel and traffic type to send traffic based on the destination area, the QoS of the segment passing through the GVN, and other factors.

At the GVN layer—GVN4-1, the physical conditions of base station network connectivity are monitored and tested to determine the best routing options over which to build GVN tunnels and paths through them. GVN paths can be transported through connected tunnels passing through SRV_AP, SRV_BBX and other GVN hardware devices. This also determines which tunnels to continue using and which to drop.

Mechanisms, modules and components at GVN layer two GVN4-2 facilitate setting up, testing, managing and otherwise operating the pipeline between layer three GVN4-3 and GVN layer one GVN4-1. Tunnel testing 46-310 can be done in layer three at EPD 4100 and at SRV_AP 46-300 via its tunnel tester 46-312.

Figure 47 shows Advanced Smart Routing (ASR) features and elements of the GVN's Geographic Destination mechanism within an End Point 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 VIF 347-118 to Internet 47-004; 2) Traffic destined for other areas Internet 47-002 will pass 1' _1102-6 to route 47P48 to SRV_AP47-300 and then to Internet 47-002 via route 47P50; 3) Traffic for other regional Internet 47-006 will go from VIF247-116 via TUN2102-8 to route 47P52 to SRV_AP47-302 and Then via path 47P54 to Internet 47-006; and 4) traffic for other area Internet 47-008 will go from VIF347-118 through TUN3102-10 to path 47P56 to SRV_AP47-304 and then via path 47P62 to Internet 47-008.

SRV_AP 47-304 includes more details to show some functionality of its components AP Logic 47-314 and Content Pull Proxy 47-318. In addition, EPD 100 includes a more detailed flowchart to illustrate its internal functional components.

Tunnels TUN1102-6, TUN2102_8, TUN3102-10 and traffic flows through the VJF with routing tables applied at each of the virtual interfaces VIF147-112, VIF247-116, VIF347-118 operate in a similar manner to virtual interfaces and tunnels.

The DNS cache 47-114 is seeded from multiple DNS sources via the local DNS lookup mechanism 47-110 to the Internet 47-004 via the path 47P38 via 47P34 to SRV_DNS 47-104. The Remote DNS Query Mechanism 47-108 may make DNS requests to SRV_DNS 47-114 via 47P44 via a Content Pull Proxy (CPA) 47-318.

The Geo Destination mechanism (Geo-D) pushes routing information to the Routing Manager 47-104 via 47P04 connecting the Content Delivery Agent (CDA) 47-106 with the CPA 47-318. Path 47P30 to 47P40 via JO1 is an abstraction representing the coordination of CPA47-318 working with GDA47-106. Communication between CPA & CDA is still via tunnel and or API calls, or via linked cache transfers, through tunnels, or may be via other mechanisms.

In this example embodiment, with 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 content from the host server 47-110 hosting the destination content via 47P66, And within that content the CPA 47-318 may find links for 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 host server 47_112 via 47P68. Often many websites host web pages on one server, video files stream from another server, and graphics are served from another server.

FIG. 48 shows an example of multiple parallel-type traffic paths taken via the GVN. The left side of EDGE-1 indicates the LAN side. Right means the internet is facing sideways. The right side of EDGE-2 represents the LAN side and the left represents the Internet facing side.

Traffic from devices in LAN001 leaves EPD 101 via P002 through encrypted tunnel P003 to SRV_AP 102 and can flow out to general Internet 106 to reach host client or server device D005 via path H005. Traffic from devices in LAN 201 leaves EPD 301 to SRV_AP 302 via P103 and can flow out to 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 . There is a secure tunnel between EPD and SRV_AP via paths P003 and P103. To ensure complete security, the path between EPDs is EPD101 to P005 to SRV_AP103 to P007 to WAN107 to P107 to SRV_AP302 to P105 to EPD301 for an end-to-end secure tunnel.

EPD 101 can build a secure tunnel via P003 to SRV_AP 102 and link from there to another secure tunnel via P201 to WAN 103 to P202 to SRV_AP 104 and then flow out in the remote area to the Internet 105 via path P203 and to the hosting client via path H002 end or server device D002.

EPD 301 can build a secure tunnel via P103 to SRV_AP 302 and link from there to another secure tunnel via P301 to WAN 303 to P302 to SRV_AP 304 and then flow out in remote areas to the Internet 305 via path P303 and to the hosting client via path H004 end or server device D004.

The EPD 101 is also able to reach devices in the Internet 305 via a secure tunnel between the EPDs 101 to SRV_102 to SRV_AP 302 to SRV_AP 304 , and flow out from there to the Internet 305 .

EPD 301 is also able to reach devices in Internet 105 via a secure tunnel between EPD 301 to SRV_302 to SRV_AP 102 to SRV_AP 104 , and flow out from there to Internet 105 .

Numerous other options exist for routing via end-to-end tunnels, tunneling to egress points on the open Internet, tunneling via multiple SRV_AP devices, and other options.

The important point shown by this example is that client traffic carried by GVN is through GVN Layer 3 which from the client's perspective takes the same path through GVN Layer 3 as through the Internet and is therefore capable of carrying any type of traffic through it , although the improved benefits and higher degree of safety offered by GVN are still recognized.

For example, path P008 shows WAN optimized connectivity between firewall GW002 device and firewall GW202 device to create a LAN-WAN-LAN bridge. Device-to-device communication is carried within the third layer of the GVN and is transparent to GW002 and GW202.

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

WAN in this example embodiment represents a secure tunnel between GVN devices over the Internet, and thus any reference to WAN is at layer three of GVN, where all GVN traffic still travels layer one.

Figure 49 depicts Automatic Advanced Smart Routing (ASR) from a device 49-000 at the beginning to an endpoint device 49-800. If a route is not available, automatic advanced intelligent routing can build routes, including but not limited to building new tunnels and updating internal routes for optimal paths.

Tables 1 through 5 are used by this algorithm as data points to use 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 algorithms to help distinguish which route is preferred over another.

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

Table #1 - Assessing QoS for various routes through GVN

指示在两个设备之间的路由路径。这可以作为互联网之上的网络段，作为隧道或其他机制(可能作为GVN的部分)直接通过互联网或经由设备之间的其他网络路径。起始点在左侧并且目的地意味着流量将路由至或从此路由的最后位置。EPD[EIP] and SRV_AP2[EIP] indicate the egress/entry point (EIP) from the device to the Internet or from the Internet to the device. double arrow symbol

Indicates the routing path between two devices. This could be as a network segment on top of the Internet, as a tunnel or other mechanism (possibly as part of a GVN) directly over the Internet or via other network paths between devices. Origin on the left and Destination means the last location the traffic will be routed to or from.

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

Table 2 describes the server availability matrix.

Table #2 - Server Availability Matrix

Information maintained in the server availability matrix includes Server_ID, Server IP_Address_ID, Port Number, EPD_ID fields, parameter fields (including security and configuration settings, status flags and time stamps).

The PRI is a weighted priority order for servers connected to the EPD. Priority 1 is the absolute lowest priority. 0 indicates that the server is currently unreachable. This differs in Flag_State, which indicates whether the record is current or not. The PRI can be kept in the same table or in another related table, since the PRI is a continuously changing value and another table would allow 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 that it can be used. Flag_State being -1 indicates that it has been retired and cannot be used.

Table 3 shows the delay times of the complete paths and the delay times constituting the network segments.

Table #3 - Routing -> Path Latency Evaluation

The path from the LAN to the GVN via the EPD and or the Internet or a combination of various network segments has a total path latency, otherwise known as RTT, Round Trip Time Delay. The time is in milliseconds (ms) and is for ICMP pulses from origin to destination and back to origin.

In order to evaluate the optimal route, it may be split into groups of network segments which form constituent parts of the overall network path. The evaluation of the various segments can provide information about the route and provide data points that can be used. Path ratings will always give traffic an extra priority weight to GVNOTT for transiting the Internet versus traffic for transiting 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 transit plus GVN outflow to 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 kept as a log record of current and historical QoS (Quality of Service) results for routes between the source peer and another peer in another location and or zone. It can be used in real-time to make QoS desired decisions based on real-world conditions. This table is located on each origin device and indicates routing performance.

Various factors are used to evaluate the line quality comparison. Such factors include system load (load), security (SEC), round-trip delay (RTT), packet loss (R-reliability), bandwidth (BW), hop count (EFF-efficiency), and other factors (which can be used to Array of values to evaluate line parameters).

Baselines and network segments in between are taken for each point so that comparisons can be made between resources with different hardware configurations and network speed, bandwidth, and other ratings.

L_ID indicates a line ID for recorded routing information.

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

Reg_ID is the target region ID.

RTT is round trip time or latency based on historical standards. A value of 1.0 is standard, while greater than 1.0 indicates a lower than usual delay time and less than 1.0 indicates a greater than usual delay time.

SEC is a safety rating. A value of 1.0 is safe, and a value of 0.0 indicates a completely unsafe and completely compromised resource. This is based on safety testing, performance records and other data points. Any value below 1.0 is of concern.

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

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

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

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 connectivity of said route RT_ID from one point to another Twice the bandwidth of comparable baseline performance with 10% lower latency and average routing between the points.

For example, where RT_ID=5, a security rating of 0.80 indicates that there is an ongoing security risk, and a relative available BW rating of 0.30 shows that the server is under attack such as DDoS or BruteForce, where multiple security threats such as multiple Onslaught of parallel requests that saturate the available BW (bandwidth) while reducing the 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 (seconds since said moment).

L_ID=3*L_ID=5 shows a comparison between two different UNIX timestamps 1448674238 and 1448848558 from the starting point to the region Reg_ID=44. It shows that the subsequent performance has improved from the previous rating. A load of load = 0.9 is preferred relative to load = 0.7, and basic network connectivity has also been improved.

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

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

Table #5 - EIPs in Regions

The ATR field is an attribute field. This is an array of attributes used to describe the EIP specification (RAM, cores, memory space, other factors, etc.). The S_ID field holds the server ID and the PJD field holds the IP address ID. Bandwidth (BW) is measured in GigE. For example, 20Mbp is 0.02, 100Mbp is 0.1 and 1GigE is 1, and 40GigE is 40.

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

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

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

Figure 50 shows 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.

There are two layers of natural protection in place. The first layer of protection is that the only way to join the two layers together is via paths 50-TR6B22 and 50-TR6B32 and must pass through the security perimeter. Only valid GVN traffic may pass in either direction via both logical checks. Other security protections in place are that the network types above and below the security perimeter 50-182 are different.

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

From a starting point at a host client 101 device in a local area network (LAN) 102 connected to an endpoint device (EPD) 103, the GVN provides a multitude of connection paths from the EPD to multiple potential end points. This is a flow chart is a high-level diagram of routing logic, packets can be seen as it uses ASR to transmit GVN for optimized performance. From the perspective of the host client 101, its traffic will flow through the Internet Protocol (IP) network, due to the very few hops and the best possible delay time of the third layer of the GVN. The first layer of GVN is an auto-configured internetwork of base stations with the construction of virtual interfaces, tunnels, routing and other network policies. The second layer of GVN is

Algorithms, software, and logic govern the layers of operation between layers three and one.

The first major routing decision is at logic gate 104 within the EPOD, where traffic goes out to the local internet 107 (where Ero is located via path P104) or if it will go through a securely wrapped and obfuscated tunnel via P107 to the access point server ( SRV_AP) 110, then provide the best 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 . Traffic going out locally to the Internet 113 will go to the host client 115 or host server 116 there via path P111. If the traffic is not local but relayed to another area, it will go to the next SRV_AP 119 via tunnel 118 via path P116.

At SRV_AP 119, three of the many possible routing options are shown by the paths the traffic can take. The logic gate 126 determines whether the traffic should stay and go out to the local Internet 129 or whether the traffic should be tunneled to the SRV_AP in another area 127 via P126. Another possibility is shown via path P119, which indicates a tunnel from the SRV_AP 119 to another EPD 121 in the remote area. This is EPD103 to EPD121 bridged via multiple bridged tunnels.

A further possibility is that the traffic reaches the client device 125126 in the LAN 122, where the EPD 121 is located via the connection P121 of the EPD.

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 not shown or discussed.

Path 52CP00 from client C52-002 to EPD 52-108 can be used to measure the performance of the client over LAN to ETO. Matching of the best routes is performed after testing and evaluating real-time data of available routes. From the EPD the GVN enters the access point servers (SRV_AP) 52-102, 52-104, 52-106, 52-202, 52-204 via the first hop 52CP00.

A path from the EPD to the first SRV_AP may be defined as an entry point from the EPD into the GVN and measured thereby. Internal hops from SRV_AP to SRV_AP follow internal routes that always try to maintain the best path connectivity. These could be OTT Internet, over backbone, over dark fiber, or other related routes.

The best egress point outside the GVN also maintains a local trace that is in this remote area and also overall for the complete network segment from the origin to the destination.

Tests can be run on individual segments, combinations of segments, and the total network path from one end to the other, taking into account the various factors assessed. Traffic type and path determination can be based on data attributes and profile QsS requirements. Primary path selection is always based on the best factors for traffic over the path. The function of this mechanism is to match the path between the destination and the origin to route the flow for the best possible bi-directional.

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

Table #6 - IP Addresses to Save Locally

This table holds which IP addresses are to be kept locally so that EIPs (egress/entry points) are transported directly on the EPD or via SRV_APs in the same area as the EPD. said

The LRI_ID field holds the local routing IP address ID. A zone value of 0 indicates that IP addresses (etc.) to be kept locally should go directly from the EPD to the Internet from their local EIP. Regional values 1 to 300 indicate countries and regions. Region values with higher region IDs indicate finer granularity. IP4J; Also the address field holds an IPv4 address.

Under a column such as protocol or port, an asterisk ("*") means that the wildcard covers all possible values in an allowed range or set in a list of allowed values. If one or more values are in a column and separated by commas, it indicates that more than one port, or protocol, or other column value may be used. Then only those values explicitly stated 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 EPDIDs to which these rules apply.

Table #7 - Table of IP Addresses to Route via Geographical Destinations

The GDReg_ID field holds a geographic destination ID. A zone value of 0 indicates that IP addresses (etc.) to be kept locally should go directly from the EPD to the Internet from their local EIP. Regional values 1 to 300 indicate countries and regions. Region values with higher region IDs indicate finer granularity. The IP4_Start and IP4_End fields hold the start and end IPv4 addresses.

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

Table #8 - Benchmarks for IP Addresses Per Zone

This table defines IP address ranges for either nationwide blocks or regional blocks, depending on the granularity employed for regional routing. Geographically destination-routed addresses are routed in order before the regional IP address table and thus are routed first.

The CIPB_ID field holds a national IP address block IDXIDR4 column indicates a range of IPv4 addresses CIDRXIDR stands for Classless Inter-Domain Routing, which is a notation describing a range of IP addresses. For example, the slash eight (/8) symbol represents 16,780,000 1s? address block. Slash twenty (/20) represents 4,096 IP addresses. The Total_IP4 column indicates the total number of IPv4 addresses covered by the range defined by CIDR4.

Figure 53 is a flow diagram of an algorithm controlling the routing of traffic from an origin device to an endpoint device.

In the GVN there are routing tables for the routing of the base level Internet between the GVN device 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 that has been routed through the GVN at level 3. Sometimes, a tunnel may not exist or if a tunnel exists, it may not be optimal. GVN routes can be mapped to existing and potential GVN routes according to the topology database. All information about basic network segments and links between devices is stored in the GVN database.

The algorithm starts by identifying target areas for specific GVN traffic. Next, a check is made to see if the path exists via GVN5306. If the path does not exist, then build a new tunnel 5310. The next step is to check the health of the tunnel 5312. If it is unhealthy, a new replacement tunnel will be constructed 5310. Once the healthy tunnel is available, check the route health 5320.

If there is a route in the target area 5322 for the path to the EIP and checks that route to see if it is the best route for the type of traffic. If it is the best route, then use said route 5360.

If the route is not ideal for the data type, then a check is made to see if there is an alternative 5350. If an alternative exists, the best route for the traffic type is taken 5352 and that best route is used 5360 . When routing is used, the process evaluates routing performance 5365. Another process saves performance data via P5328 in a log on server availability, on the list of EIPs 5322 and also on the mapping path used by 5302 to the target area before the algorithm is complete.

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

control

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

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

Each device EPD100, SRV_AP200, and SRV_CNTRL300 stores information about itself in a local information repository in the form of lists, files, database tables and records, and otherwise. This repository also includes information about peer device relationships, storage logging, and other relevant operational information. The SRV_CNTRL200 also has additional storage capabilities and its role is to provide information to other devices related to it and/or to peer devices that may be connected to it, in order to evaluate the current status and provide guidance similar to centralized control, such as publishing a list of server availability and other functions. The Neutral API Mechanism (NAPM) can send information between devices and connected peers of those devices, 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_CNTRL200 servers in many locations acting as multi-master devices. 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 functions, trigger scripts, and other mechanisms.

Figure 55

Figure 55 shows communication between EPD 100, SRVCNTRL 200 and SRVAP 300 via paths API-55A1-55A2, API-55A3-55A2 and API-55A1-55A3 via GVN's Neutral API Mechanism (NAPIM).

For tunnels TUN55-1, TUN55_2 and TUN55-3 to be built between EPD100 and SRV_AP300 and for tunnels from EPD100 to other SRV_AP servers such as TUN55-4 and from other EPDs to SRV_AP300 via TUN55-5, in peer-pair Individual devices in require specific information for each tunnel.

The NAPIM mechanism stores relevant credentials, coordinates and other information for each side of the peer pair employed when building a new tunnel via the tunnel managers 55110 and 55310. The Server Availability Mechanism 55222 on the SRV_CNTRL 300 evaluates the performance of the various tunnels tested on the EPD side via the Tunnel Tester 55112 and on the SRV_AP side by the Tunnel Tester 55312. Information from the tests is relayed to the Connectivity Analyzer 55288 on SRV_CNTRL200. Test results include assigned IP address and port combinations, used ports, results from historical combination usage, results from port spectrum tests, 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. 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 EPD 100.

Server Availability Prioritizes the list of SRV_APIP address and port combinations based on the desired best performance for the constructed tunnel, while also viewing the current load of available SRV_AP servers, balancing the list of assignments to other EPDs, and other available information.

Figure 56 shows various types of communication available between GVN devices via NAPIM.

Closed loops can be used for NAPIMREQ/RESP communication between pairs of known peers and there are two main types; device-to-repository 56-P2C and device-to-device 56-P2P.

A RESTfulURL publication is open access to unknown peers, such as generic 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 as to whether authentication is required, plus other controls. For example, EPD 100 may request via 56REQ100200 a list of available servers and corresponding IP addresses and ports 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 NAPM, through database replication, via back channel, or other messages.

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

API call group 57202 represents calls from the central server (SRV_CNTRL) 200 via path P57202-C, calls to the endpoint device (EPD) 100 via P57202-B, and calls from the access point server (SRV_AP) 300 via P57202-A. This type of communication can exchange information about tunneling information, log information, billing information, device peer pair data, and other forms of related information between the repository database and file storage on the SRV_CNTRL200 and EPD100 and SRV_AP300 .

There are two types of communication paths between EPD100 and SRV_AP300. Direct tunneling between them pushes Layer 3 traffic, information and binaries as packets via the path P57206-C. Between the EH) 100 and the SRV_AP 300 there is also an API call structure 57206 realized via the path from P57206-B to 57206 to P57206-A.

The direct connection between EPD100 and SRV_AP300 via API57206 can be used for information sharing, collaboration and authentication among other information. For example, an attempt to restart a tunnel can often be triggered by one side, with the other automatically responding and rebuilding it. However, in the event that the tunnel is blocked and cannot be re-established, the API can be used to send commands to try to force the tunnel to restart on both ends, and if still unsuccessful, the information can be shared between the devices. This information may trigger the need to use new tunnel information to build a different tunnel between the two devices, or cause both devices to send queries to SVR_CNTRL 200 for new tunnel building information. Therefore, it is very useful to establish a communication path between them via API57206.

API call group 57208 represents calls made via path P57208-C from CNTRL_SRV200 and internal back-end infrastructure equipment and other infrastructure support equipment of GVN. For simple description, some gateway devices are shown in this example embodiment, and there may be other types of infrastructure devices connected to SRV_CNTRL via this path in the GVN not shown here.

SRV_GW_Email 57310 represents an email server, and is linked to 57208 via P57208-B1, which is linked to P57208-C, and thus linked to CNTRL_SRV100. Email can be sent and received via Email Network Access Point (NAP) 57401. A dedicated email server enables other devices to focus on their own functions and also provides simplified management as it is the only type of device that requires maintenance in terms of email server management.

SRV_GW_FIN57318 represents a financial gateway server, which can be used to conduct credit card and other financial related transactions with third parties via external API57501NAP. As with the example SRV_GW_Email, a device-type persona focused on a single function enables other devices to focus on their core functions and provides simplified management as only additional management of the SRV_GW_FIN server is required to secure financial transactions with third parties.

SRV_GW_Other 57315 indicates other types of gateways between GVN and other services on the Internet. Communication between these types of gateway servers and SRV_CNTRL200 is accomplished via P57208-B3 to 57208 to P57208-C.

The secondary API path between SRV_AP300 and SRV_CNTRL200 is via P57208-A to 57208 to P57208-C and exists for redundancy purposes and for infrastructure related communication between this peer pair.

Another set of calls from the SRV_AP server may establish a path from SRV_AP300 to SRV_GW_Email 57310 via a path from P57208-A to 57208 to P57208-B1; and via a path from P57208-A to 57208 to P57208-B2, Establish a path from SRV_AP300 to SRV_GW_FlN57218; to and via a path from P57208-A to 57208 to P57208-B3, establish a path from SRV_AP300 to SRV_GW_Other57315. These can implement API calls for data exchange directly from SRV_AP300 to these devices.

API calls transmitted via P57208-A can also represent relayed API calls made by other devices via SRV_AP300, for example from EPD100 via path P57206-B to 57206 to P57206-A to 300 to P57208-A to 57208 to P57208-B2 The call to SRV_GW_FIN57318, in this case the API call flow through SRV_AP300 is just another hop in the chain where the client is EPD100 on one end and the server is SRV_GW_FIN57318 on the other end.

API calls and other types of information exchange are critical to the operation of devices in GVN. There are several types of automated infrastructure operations. These operations include: keeping device OS configurations up-to-date; updating software packages for O/S and modules from reliable repository sources that can accommodate updated software for easy and predictable patching, updates, and latest installs; deploying new Globally virtual network software modules and keep installed modules updated; perform controlled replication of GVN databases; keep API operations library up-to-date; and other operations.

On each device, there are daemons and heartbeat functionality where automation and inter-device interaction is required. This includes keeping background programs running, keeping services online, keeping queues online and keeping them unblocked, heartbeat functions, logging functions.

Connectivity and fabrics in GVN include virtual interfaces (VIFs), tunnels, multiple tunnels, routing, server availability, geographic destinations, DNS, and caches and links.

Up-to-date information is required for tunnel establishment, and this information needs to be shared between client and server, otherwise the tunnel will not be established. Therefore, testing and diagnostics are required while reporting the resulting data for centralized analysis in order to understand the overall functioning of the GVN. Test and diagnostic information may include: Layer 1 conditions; tunnel connectivity; optimal point-to-point routing over the Internet; Advanced Intelligent Routing (ASR) for optimal routing through the GVN; and device operational status.

An API can also be used to communicate information about itself, such as peer pair information, queue information, transaction logs, security/accounting and other logs, and related API actions, schemas, data structures, and processing actions on the client or server. script.

Information about the status and configuration of hosted services may also be transferred via the slave device transferring API calls to SRV_CNTRL or other devices. This information may include service online/offline status, API module online/offline status and, if available, hosting status of the site, database status, Secure Sockets Layer (SSL) certificate status, GVN component status (such as geographic Destination and other components are running).

Information exchange via the API 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 self-healing mechanisms for integrity, so they can be deployed across devices.

Figure 58 describes the steps taken by an API call originating from Client Device Peer (Source) 006, sent to Server Device 007007B and back to Client 006006B.

API transactions are triggered at API start 001. Pass the data to a common class or other type of processor to create the internal payload 002. Add said internal payload to queue 003 which may be in memory, save it to a database, flat file or other mechanism. The queue step can be bypassed with an API call that sends immediately or can be set to send at a certain time. As part of the heartbeat function of the client device 006, and depending on the priority flags of the API calls in the queue, the payload can be processed immediately, at a specific time, or based on factors such as load, queue 003 length, network conditions, or other factors And delayed. When an item is processed from the queue, the external payload is prepared and the relevant transaction data 004 is generated for a special, single-purpose API call. When the external APIREQUEST payload is ready to be sent, the external payload is delivered via the neutral API mechanism 005, which in turn is sent via the Internet Q01 via the paths CP01 to Q01 to CP03 or via the secure tunnel WANQ02 via the paths CP02 to Q02 to CP04 to Peer Target 007 Host (Server) API.

After receiving 008 the request payload RP01, the server 007 will then start parsing and interpreting said payload. When processing the request payload RP01, security and data integrity checks will be done and the outer payload will be decrypted to discover the content 009 of the inner payload. Further security and data integrity checks are implemented by comparing the internal and external payloads. After verification, the payload is passed to the corresponding script to take the specified action 010. Upon completion of the request action, an internal payload 011 for the response is created. External Payload Creation 012 and Transaction Preparation 013 create External APIRESPONSE Payload RP02 using the same process used to create API Request External Payload RP01. A response is then sent back via the neutral API014.

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

Received back 015APIRESPRP02 by Peer Source API Client Device 006. Parse 016 and process 017 payload. Depending on the API action type, the data received back will be passed to the API handler script on 006. Log all transaction 018.

If 020 callback 019 is specified, then a new call will be initiated via path P019 and paralleled via path P020, the original API call being completed at API complete 022.

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

Figure 59 is a flowchart illustrating the interaction between the EPD and the SRV_AP for obtaining geographic destination functionality. Specifically, this figure depicts the processing flow of the geographic destination mechanism, starting at Client 000 and following a sequential and sometimes parallel communication path from CP0 to step 12 Endpoint Device (EPD100), where EPD100 communicates with the Access Point server interaction (SRV_AP300).

This process flow ends when the content in the remote area has been pulled to SRV_AP 300 and then sent back to EPD 100 via transmission and caching within the geo-destination mechanism to be provided back to client 000 via path CP203 in step 15 .

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

Steps 1, 12, 13 and 15 occur in the origin zone with respect to client 000 and EPD100.

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

Steps 5, 6 and 9 take place on the SRV_AP300.

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

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

Figure 60 depicts device collaboration within geographic destinations, with components generally indicated as modules and referred to on individual devices for information and information exchange stored in memory and databases, and for API traffic as well as data Transfer Information communicated via a communication path such as file transfer between devices. GVN enables control of complex automated structures stretching across multiple devices to work together to achieve a common goal.

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

Content pull agent D302 is located on SRV_AP300. CPAD 302 receives the target URL/URI from CDAD 102 located on the EPD. This target address that the client wants to reach is in another zone from the client and is where the client wants to pull the content. The CPAD 302 transmits the request address to the remote grabber B0T (R.F. B0T 301 ).

It is the job of the R.F. BOTD 301 to do a DNS lookup D304 and then use that information to pull content via data pull 301 . R.F. BOTD 301 cooperates with CPAD 302 via CP01 to parse the crawl results to find any other addresses of auxiliary content that can and should be pulled as an integral part of this content. The request is stored in database D302 for access and further reference by CPAD302 and R.F.BOTD301. The content file list L301 is transferred from the R.F.BOTD301 to the CPAD302. The data file content is transferred from Data Pull 301 to Cache Manager D 303 via R.F. BOTD 301 . Pulled files are sent to Cache Manager D303 for aggregation as files or transfer as individual files.

Depending on the distance from the origin to the geographic destination area, the file type, and the QoS, the files pulled in the cache may be aggregated as a single file delivered uniformly through chained caches or may be sent as separate files in parallel concurrent streams .

There are several alternative paths to remote regions. Data may be transmitted via the paths between the API and TP01 to TP02, the paths between TP01 and TP03, and the paths between TP02 and TP03. Data files can also be transferred via the GVN via routes CP38, CP39 or P06 to CPBB and so on. CP38 is a tunneled path from SRV_AP300 to SRV_APD555 via GVND888. CPBB is a trunk path between SRV_APD555 and SRV_AP300 via relay SRV_APD505 path P06. CP39 is a file transfer path from cache 701 to EPD 100 via SRV_APD 555 over the GVN. CP02 indicates the direct connection path possibility between SRV_AP300 and EPD100.

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

Fig. 61 shows how globally distributed Parallel File System (PFS) is connected via GVN. Specifically, this figure shows how a globally distributed Parallel File System (PFS) can allow seamless access through the GVN Over-the-Top-of-Fibre (OTT) framework (Tapestry) using local RDMA One of the three 61308, or 61318, or 61328 PFS storage nodes can be connected to one of the three 61308, or 61318, or 61328 PFS storage nodes to achieve the required quality of service (QoS) and comply with the high performance computing (HPC) principles required for this functionality.

PFS61308 is an example of one PFS instance in a client LAN behind EPD linked to two other PFS instances "in the cloud", where local RDMA over IB between all three PFS storage nodes allows true parallel access , regardless of the network type at the base segment. Link 61CP06 is the basic internet connection between EPD100 and SRV_AP300 and TUN1 is running at OTT of 61CP06. 61CP10 is within the IDC or 0TT Internet. The PFS61308 is connected to the PFS61318 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.

SRV_AP300 is connected to SRV_BBX61310 via 61CP10 and both are located in the same global node.

PFS61318 is connected to PFS61328 via SRV_BBX61310 connected to SRV_BBX61320, which represents global node-to-global node long distance communication via GVN.

The scope of the invention is not limited to the specific embodiments described herein. In fact, in addition to the content described herein, those skilled in the art can clearly understand other multiple embodiments of the present invention and modifications to the present invention from the above description and accompanying drawings. Accordingly, such other embodiments and modifications are contemplated within the scope of the present invention. Furthermore, while the invention has been described in the context of at least one particular embodiment in at least one particular environment for at least one particular purpose, those of ordinary skill in the art will recognize that the usefulness of the invention is not limited thereto , and the invention can be beneficially practiced in any number of environments and for any number of purposes. Accordingly, the appended claims should be interpreted in accordance with the full breadth and spirit of the invention described herein.

According to the embodiments of the present disclosure, the following additional notes are also disclosed:

1. A network system for connecting devices via a global virtual network, comprising:

a first device communicatively connected to the first endpoint device;

a second device communicatively coupled with the second endpoint device; and

a communication path connecting the first endpoint device and the second endpoint device, the communication path further comprising one or more intermediate tunnels connecting each endpoint device to one or more intermediate tunnels Access point server and one or more control servers.

2. The network system according to supplementary note 1, wherein at least one of the first endpoint device and the intermediate access point server is configured to perform a domain name system lookup in order to locate the second device.

3. The network system according to supplementary note 1, wherein at least one of the first endpoint device and the intermediate access point server is configured to perform a domain name system lookup from a cache in order to locate the second equipment.

4. The network system according to supplementary note 1, wherein at least one of the intermediate access point servers is configured to cache content.

5. The network system according to supplementary note 1, wherein at least one of the endpoint device and the intermediate access point server is configured to perform intelligent routing.

6. The network system according to supplementary note 5, wherein the intelligent routing is based on at least one of optimal bandwidth, lowest delay time, least hops and no packet loss.

7. The network system according to supplementary note 5, wherein the intelligent routing is based on at least one of real-time statistics and historical statistics.

8. The network system according to supplementary note 1, wherein at least one of the endpoint device and the intermediate access point server is configured to perform a firewall service.

9. The network system according to supplementary note 8, wherein the first end point device provides a firewall service between the first device and the intermediate access point server.

10. The network system according to supplementary note 8, wherein the intermediate access point server provides firewall services between the first endpoint device and other intermediate access point servers or the second endpoint device.

Claims (6)

1. A network system in a global virtual network, comprising:

a first device;

a second device;

a plurality of intermediate access point servers forming a plurality of end-to-end tunnels connecting the first device and the second device; and

a plurality of host devices, wherein a first host device of the plurality of host devices communicates directly with the first device or the second device, and a second host device of the plurality of host devices communicates with the first device or the second device through one or more of the plurality of intermediate access point servers.

2. The 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.

3. The network system of claim 1, wherein at least one of the plurality of intermediate access point servers is configured to cache content.

4. The network system of claim 1, wherein at least one of the first device, the second device, and the plurality of intermediate access point servers are configured to perform intelligent routing.

5. The network system of claim 1, wherein at least one of the plurality of intermediate access point servers is connected with an endpoint device at a cloud partner organization location through an end-to-end tunnel.

6. The network system according to claim 1 or 2, wherein at least two of the plurality of end-to-end tunnels are bound as one end-to-end tunneling traffic.

Images