Decenter Network Engine
Decenter Network Engine
Network Syborg: Deorchestrates - Manages - Secures
High Performance Decentralized Automatic Satellite Switch_
[ TYPE : Built-in ]
SynchroKnot vSoC comes built-in with an actual Decentralized High-Performance Automatic Layer 2 Ethernet Satellite Switch integrated with the Satellite Tree Protocol.
The vSoC automatic Satellite Switch allows vSoCs to be ☼ directly ☼ connected to each-other utilizing proven network topologies and without having to configure anything! ☼ ZERO CONFIGURATION - ALL-AUTOMATIC ☼
The vSoC Satellite Switch is an ☼ ACTUAL ☼ switch as seen in products from Cisco, Juniper and others, and not a virtual switch like Open Virtual Switch [OVS] and related software.
With this unique built-in automatic functionality, if you prefer, you ☼ DO NOT ☼ need physical or virtual switches anymore.
Features & Highlights:
▸ Decentralized - All-Automatic - Mission-Critical - Resilient - Self-Sustaining - Self-Healing - Seamless Scaling Without Down-Time - Ultra High-Performance.
▸ Nothing to configure or manage. All-Automatic.
▸ Integrated with SynchroKnot Satellite Tree Protocol [ SSTP ] - Enhancement to the IEEE standard [ 802.1D (1998|2004), 802.1W ] while keeping the core semantics in place. Standard Layer 2 Ethernet remains pure, untouched and unmodified without frame encapsulation, additional headers or other forms of tinkering.
▸ Improving upon and applying the globally accepted IEEE standard found in standard physical network switches and products directly into the networking core of the SynchroKnot vSoC. Network is no longer a separate complex component with separate hardware and licenses, but is now built right in with nothing extra that needs to be done.
▸ Depending on your need and/or requirement, you now have a logical straight-forward option and ability to eliminate Top-of-the-Rack, Spine, Leaf, Edge, Aggregation and Core Switches & Routers, along with their respective licenses. There is no need for multi-stage network switching as seen in Fat Tree and related networks and topologies.
▸ Large-Scale, High-Performance Layer 2 Network Environment with just a single instance of Satellite Tree Protocol with support for single, double and triple stacked VLANS.
▸ Does not cause a network-wide outage on failure of link(s) as experienced with regular Spanning Tree Protocol [ STP ] and Rapid Spanning Tree Protocol [ RSTP ].
▸ Recovery from failure is, in most cases, in sub-milliseconds to about 1.5 seconds depending on the nature of failure [ single / multiple links within and across vSoC Cluster[s] or single / multiple vSoC[s] themselves ] and the distance from the point[s] of failure. Traffic that does not traverse the path where failure occured is generally not affected by the failure at all.
▸ Intelligent Layer 2 Optimized Cost Multipath forwarding logic based on local decentralized intelligence chooses the best link with the shortest optimal path in normal operation, congestion and on link failure.
▸ Multiple ☼ ANY-to-ANY ☼ Layer 2 routes allow the addition and removal of vSoC[s] seamlessly and transparently without turning off whole or sections of the network, as experienced with switches and routers in networks today.
▸ Combine different Ethernet network interfaces for the best cost & performance - 2.5 Gbit/s | 5 Gbit/s | 10 Gbit/s | 40 Gbit/s | 100 Gbit/s | 200 and 400 Gbit/s & Terabit Ethernet [ when available ].
▸ ☼ Zero Configuration ☼ - How about never having to endure countless hours of pain configuring, managing and maintaining physical Ethernet ports, trunking and ACLs and other aspects? How about plugging one end of Ethernet cable into ANY physical port of a vSoC and connecting the other end to ☼ ANY ☼ physical port of another vSoC and that's it - nothing to do.
▸ Get the best of cost, low latency, bandwidth and performance in multiple directions, not just East-West / North-South with the help of SynchroKnot Multi-Dimensional topology.
▸ SynchroKnot Multi-Dimensional topology is a dynamic mix and integration of proven network topologies which are used as a primary backbone in High Performance Computing and Supercomputing. These include Ring, 2-D, 3-D and many other custom topologies optimized for cost, performance and simplified cabling.
▸ Seamlessly scale and expand the vSoC super cluster in an incremental and highly granular manner while the vSoCs are fully functional and operational. No down-time or cluster-wide network re-cabling. The vSoC super cluster can be expanded either by adding individual nodes at X, Y or Z axis [depending on the type of topology being used] OR a separate vSoC super cluster can be cabled, made operational and tested on the side, and then simply connected to the main super cluster to bring about rapid cluster expansion locally or globally.
▸ Single-length cable for the entire vSoC super cluster. No long haul cables. No expensive power-consuming optical cables. Minimize the cable acquisition, stocking and management costs.
▸ Significant reduction in latency and substantial performance improvements, as no external switches and routers are involved.
▸ No Channel Bonding / Link Aggregation / NIC Bonding / EtherChannel means no maintenance and no performance degradation.
▸ Can be controlled and managed with standard Linux network tools and utilities. For example, if needed, it is possible to manually access and manage the Forwarding Database [ FDB ] and related aspects with IP, Brctl, Bridge and related tools and utilities.
▸ Very low CPU usage.
▸ Automatic Layer 2 Traffic Re-Routing using decentralized logic if a vSoC ascertains that it has low resources. [Un-Released Feature]
▸ Enhanced version of Satellite Tree Protocol for separate and combined wireless, satellite and wired networks. [Un-Released Feature]
2 Port NIC for 1-D Ring | 4 Port NIC for 2-D Torus
Seamless Network Expansion of 1-D Ring [single length cable]
2-D Torus Topology
Seamless Incremental Network Expansion of X & Y Axis
Multipath Optimized Routes for Mission Critical Operation
SpaceBuoy - Secure Decentralized DHCP_
[ TYPE : Built-in ]
SpaceBuoy is Secure Decentralized DHCP.
SpaceBuoy assigns Dynamic Static Public / Private IP addresses to the Decentralized Virtual Machines.
▸ ☼ No need to touch the Decentralized Virtual Machine. ☼
▸ ☼ Assign ANY :
   ▸ ▸ Name
   ▸ ▸ IP Address [ Public/Private IPv4 IP Address ]
   ▸ ▸ Netmask
   ▸ ▸ Broadcast
   ▸ ▸ Default Gateway
   ▸ ▸ MTU [ Maximum Transfer Unit ]
   ▸ ▸ NTP
   ▸ ▸ DNS
   ▸ ▸ Domain Name
   ▸ ▸ Domain Search
   ▸ ▸ Log Server
   ▸ ▸ NETBIOS [ Name Servers, Datagram Distribution and Node-Type ]
   ▸ ▸ SMTP server
   ▸ ▸ POP3 server
   ▸ ▸ Enable IP Forwarding
   ▸ ▸ Set TCP Keepalive
   ▸ ▸ Set Multiple Classless Static Routes and more. ☼
▸ Each Decentralized Virtual Machine's virtual network interface [ vNIC ] has its own secure lightweight DHCP server.
▸ Not affected by centralized DHCP server[s] failure.
▸ Not affected by malicious injection, takeover of the centralized DHCP server[s].
▸ No DHCP broadcast floods. Converts all DHCP broadcasts into unicast.
▸ Does not allow DHCP traffic to get onto the network.
▸ All-Automatic. Nothing to manage.
▸ SpaceBuoy is IPv4 only. [IPv6 version of the SpaceBuoy is expected to be available in the near future.]
Flood Control_
[ TYPE : Built-in ]
Flood Control is a built-in mechanism for protection from various types of flooding within and across the vSoC super cluster[s].
▸ It is designed to reduce the number of specific types of packets exiting the virtual machine.
▸ Works with ARP, Multicast, DHCP4 [IPv4], DHCP6 [IPv6], DNS and IPv6 related Router Solicitation, Router Advertisement, Neighbour Solicitation and Neighbour Advertisement.
▸ No agent / software needs to be installed in the Decentralized Virtual Machine.
▸ All modifications are performed in real-time.
DHCPCAST - Unicast DHCP_
[ TYPE : Built-in ]
DHCPCAST is Unicast DHCP.
DHCPCAST automatically converts DHCP broadcast requests originating Decentralized Virtual Machine's chosen virtual network interface [vNIC] to unicast, and sends it to the specified DHCP server, thus securing and reducing network noise caused by incessant broadasts.
▸ Transparently point single or dual stack IPv4 / IPv6 DHCP clients inside the virtual machine to your choice of specific DHCP Server [ physical or virtual machine ].
▸ Works with IPv4 DHCP client to server communication [ Discover, Offer, Request, ACK ], and IPv6 DHCP client to DHCP6 server communication [ Solicit, Advertise, Request, Reply ].
▸ No agent / software needs to be installed in the virtual machine. Should work with standard DHCPv4 and DHCPv6 clients and servers.
▸ For example, DHCPCAST can be enabled on one virtual network interface [vNIC] and SpaceBuoy on another. The DHCPCAST-enabled virtual network interface [vNIC] will get an IP address from the specific DHCP server where it is pointed at, and SpaceBuoy will assign the dynamic static IP address as configured.
Disperser - Layer 3 High Performance Load Balancing_
[ TYPE : Built-in ]
Disperser is the vSoC built-in High Performance Layer 3 Load Balancer.
▸ Transparently auto-disperse [ load balance ] IPv4 traffic at kernel speed at ☼ Layer 3 ☼ without the overhead and latency of higher layers.
▸ ☼ Zero ☼ manual configuration of ports and protocols. Substantially reduces the time, management, maintenance and complexity. Auto-dispersing transparently forwards traffic to the back-end IP addresses on the same ports and protocols that hit the front-end.
▸ Per-kernel documentation should support TCP, UDP, UDPLITE, ICMP, ESP, AH, MH and SCTP.
▸ Can auto-disperse to a single IP in the back-end [ i.e single front-end IP acting as a floating IP to a single back-end IP ].
▸ Simplifies load balancing with Round-Robin scheduling with persistence per source IP address with quick & bare-minimum setup.
▸ Can be custom configured to send more traffic to certain back-end IP addresses with more processing power and less traffic to IP addresses with slower CPU cycles, helping optimize and make full use of infrastructure efficiently.
▸ Serves as a simple, scalable and high performance alternative to weighted, least connections and other complex and CPU-intensive scheduling methods used in load balancing [i.e both hardware & software load balancers].
▸ For increased security -- all load balancing and no brokering. Certificates [ HTTPS - SSL ] need to be kept on the destination and not on the Disperser.
▸ Gateway load-balancing. Setting the default Gateway within the virtual machine to the IP address of the Disperser allows for the load balancing of traffic onto different gateways in the back-end. This allows the traffic from the virtual machine(s) [or physical machines depending on your case scenario] to access the Internet / Intranet in a load balanced manner, making efficient use of bandwidth possibly across different Internet / Intranet providers [ largely untested ].
▸ Auto failure detection of dispersed links and recovery onto new or existing links [ upcoming feature ].
▸ Denial of Service protection [ upcoming feature ].
▸ Bandwith shaping and bandwidth utilization shaping [ upcoming feature ].
▸ Search, Inspect and Manipulate [add, delete and modify] connections across all front-end and dispersed links [ upcoming Power Module : DISPERSER DEEP-DIVE ].
Spaceway_
[ TYPE : Power Module ]
The Spaceway allows the vSoCs to allow specific public IPv4 and/or IPv6 address block[s] to traverse and reach their Spatial Clusters [ i.e single/double/triple stacked network of the tenants ].
With Spaceway, the outbound traffic from the Decentralized Virtual Machines can reach their gateway[s] with public IP addresses, and the inbound traffic can reach the Decentralized Virtual Machines from their public IP gateway[s].
The Spaceway removes the need for setting up a router/switch that can tag/untag single/double/triple stacked VLANs and the performing of other complex configurations and their maintenance.
To use Spaceway you need:
▸ Public IPv4 and/or IPv6 addresses, and have them associated with a spatial cluster on the vSoC.
▸ The Spaceway port must be connected to the router that has or points to the gateway with public IP address[es]. Then, the virtual machines of that spatial cluster will have inbound and outbound access to and from the Internet.
Spaceway can be invoked on multiple vSoCs. Different Spaceways can be invoked for different spatial clusters on single or multiple vSoCs. If a Spaceway for a specific spatial cluster is created on two or more vSoCs, then the virtual machines from that spatial cluster will have multiple fault-tolerant paths to reach their gateways.
Note: Depending on the use case scenario, the Power Module Spaceway may not be needed if the Spatial Fabric Traverser is used.
Spatial Fabric Traverser_
[ TYPE : Separate Spatial Fabric Traverser License ]
Spatial Fabric Traverser is a SynchroKnot Software that:
▸ Connects the vSoCs to the Public Internet Gateway Router[s]/Switch[es].
▸ Transparently traverses traffic from both Public IPv4 and IPv6 addresses to/from single/multiple Internet service providers to/from vSoC spatial clusters.
▸ Serves as a simple, fault-tolerant alternative to using standard routers/switches.
▸ Installs on any AMD64 hardware with multiple Ethernet network ports [has same operating system requirements as vSoC].
▸ Takes care of all single/double/triple stacked VLAN traffic traversing from spatial clusters on vSoCs to single/multiple Public Internet Gateways [IPv4/IPv6] from single/multiple Internet service providers.
▸ All modifications to the IPv4 and IPv6 blocks can be made at the same time and without disrupting the traffic flow of all existing IPv4/IPv6 blocks to/from spatial clusters.
Each Spatial Fabric Traverser can be connected to multiple Public Internet Gateways, which means, spatial clusters that have been given specific public IPv4/IPv6 address blocks can reach their public Internet Gateways across different Internet service providers.
With Spatial Fabric Traverser, each spatial cluster can be given IPv4/IPv6 address blocks from different Internet service providers if needed!
Multiple Spatial Fabric Traversers can be set up for fault-tolerance and load balancing with Satellite Tree Protocol [built-in].
Note: Depending on use case scenario, the Power Module Spaceway may not be needed if the Spatial Fabric Traverser is used.
SynchroKnot Limited, Hong Kong, SAR of China [ website - content ] by SynchroKnot is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Based on a work by its creator Mehul Sharma at SynchroKnot Limited, Hong Kong, SAR of China : synchroknot.[com|cloud|org].