...

_archive/technology/primitives/network/network_toc.md

@@ -0,0 +1,7 @@
+# Network
+
+<h2>Table of Contents</h2>
+
+- [ZNET](./znet.md)
+- [ZNIC](./znic.md)
+- [WebGateway](./webgw3.md)

_archive/technology/primitives/network/p2pagent.md

@@ -0,0 +1,5 @@
+# Peer2Peer Agent
+
+>TODO
+
+!!!include:zos_toc

_archive/technology/primitives/network/planetary_network.md

@@ -0,0 +1,54 @@
+![](img/planetary_lan.jpg)
+
+# Planetary Network
+
+![](img/planet_net_.jpg)
+
+
+The planetary network is an overlay network which lives on top of the existing internet or other peer2peer networks created. In this network, everyone is connected to everyone. End-to-end encryption between users of an app and the app running behind the network wall.
+
+Each user end network point is strongly authenticated and uniquely identified, independent of the network carrier used. There is no need for a centralized firewall or VPN solutions, as there is a circle based networking security in place.
+
+Benefits :
+- It finds shortest possible paths between peers
+- There's full security through end-to-end encrypted messaging
+- It allows for peer2peer links like meshed wireless
+- It can survive broken internet links and re-route when needed
+- It resolves the shortage of IPV4 addresses
+
+
+Whereas current computer networks depend heavily on very centralized design and configuration, this networking concept breaks this mould by making use of a global spanning tree to form a scalable IPv6 encrypted mesh network.  This is a peer2peer implementation of a networking protocol.
+
+The following table illustrates high-level differences between traditional networks like the internet, and the planetary threefold network:
+
+| Characteristic                                                  | Traditional | Planetary Network |
+| --------------------------------------------------------------- | ----------- | ----------------- |
+| End-to-end encryption for all traffic across the network        | No          | Yes               |
+| Decentralized routing information shared using a DHT            | No          | Yes               |
+| Cryptographically-bound IPv6 addresses                          | No          | Yes               |
+| Node is aware of its relative location to other nodes           | No          | Yes               |
+| IPv6 address remains with the device even if moved              | No          | Yes               |
+| Topology extends gracefully across different mediums, i.e. mesh | No          | Yes               |
+
+## What are the problems solved here?
+
+The internet as we know it today doesn’t conform to a well-defined topology. This has largely happened over time - as the internet has grown, more and more networks have been “bolted together”. The lack of defined topology gives us some unavoidable problems:
+
+- The routing tables that hold a “map” of the internet are huge and inefficient
+- There isn’t really any way for a computer to know where it is located on the internet relative to anything else
+- It’s difficult to examine where a packet will go on its journey from source to destination without actually sending it
+- It’s very difficult to install reliable networks into locations that change often or are non-static, i.e. wireless mesh networks
+
+These problems have been partially mitigated (but not really solved) through centralization - rather than your computers at home holding a copy of the global routing table, your ISP does it for you. Your computers and network devices are configured just to “send it upstream” and to let your ISP decide where it goes from there, but this does leave you entirely at the mercy of your ISP who can redirect your traffic anywhere they like and to inspect, manipulate or intercept it.
+
+In addition, wireless meshing requires you to know a lot about the network around you, which would not typically be the case when you have outsourced this knowledge to your ISP. Many existing wireless mesh routing schemes are not scalable or efficient, and do not bridge well with existing networks.
+
+![](img/planetary_net.jpg)
+
+The planetary network is a continuation & implementation of the [Yggdrasil](https://yggdrasil-network.github.io/about.html) network initiative. This technology is in beta but has been proven to work already quite well.
+
+!!!def alias:planet_net,planetary_net,planetary_network,pan
+
+!!!include:zos_toc
+
+> Click [here](manual:planetary_network_connector) to read more about Planetary Network Connector Installation. Click [here](manual:yggdrasil_client) to read more about Planetary Network Installation (advanced). 

_archive/technology/primitives/network/tfgrid_network.md

@@ -0,0 +1,7 @@
+# TFGrid networking
+
+- znet : private network between zmachines
+- [Planetary Network](planetary_network) : peer2peer end2end encrypted global network
+- znic : interface to planetary network
+- [WebGateway](webgw) : interface between internet and znet
+

_archive/technology/primitives/network/webgw.md

@@ -0,0 +1,60 @@
+
+
+# WebGW 2.0
+
+The Web Gateway is a mechanism to connect the private networks to the open Internet, in such a way that there is no direct connection between internet and the secure workloads running in the ZMachines.
+
+![](img/webgateway.jpg)
+
+
+- Separation between where compute workloads are and where services are exposed.
+- Better Security
+- Redundant
+    - Each app can be exposed on multiple webgateways at once.
+- Support for many interfaces...
+- Helps resolve shortage of IPv4 addresses
+
+If (parts of) this private overlay network need to be reachable from the Internet, the zmachines initiate a secure connection *to* the web Gateway. 
+
+### Implementation
+
+It is important to mention that this connection is not a standard network connection, it is a [network socket](https://en.wikipedia.org/wiki/Network_socket) initiated by the container or VM to the web gateway. The container calls out to one or more web gateways and sets up a secure & private socket connection to the web gateway. The type of connection required is defined on the smart contract for IT layer and as such is very secure. There is no IP (TCP/UDP) coming from the internet towards the containers providing more security. 
+
+Up to the Web Gateway Internet traffic follows the same route as for any other network end point: A DNS entry tells the consumers client to what IP address to send traffic to.  This endpoint is the public interface of the Web Gateway.  That interface accepts the HTTP(s) (or any other TCP) packets and forward the packet payload  over the secure socket connection (initiated by the container) to the container.  
+
+No open pipe (NAT plus port forwarding) from the public internet to specific containers in the private (overlay) network exists.
+
+Web Gateways are created by so called network farmers.  Network farmers are people and companies that have access to good connectivity and have a large number of public IP routable IP networks.  They provide the facilities (hardware) for Web Gateways to run and terminate a lot of the public inbound and output traffic for the TF Grid.  Examples of network farmers are ISP's and (regional, national and international Telcos, internet exchanges etc.
+
+### Security
+
+Buy not providing an open and direct path in to the private network a lot of malicious phishing and hacking attempts are stopped at the Web Gateway.  By design any private network is meant to have multiple webgateways and by design these Web Gateways exist on different infrastructure in a different location.  Sniffing around and finding  out what can be done with a Web Gateway might (and will happen) but it will not compromise the containers in your private network.
+
+### Redundant Network Connection
+
+![](img/redundant_net.jpg)
+
+
+### Unlimited Scale
+
+![](img/webgw_scaling.jpg)
+
+
+The network architecture is a pure scale-out network system, it can scale to unlimited size, there is simply no bottleneck. Network "supply" is created by network farmers, and network "demand" is done by TF Grid users.  Supply and demand scale independently, for supply there can be unlimited network farmers providing the web gateways on their own 3nodes and unlimited compute farmers providing 3nodes for compute and storage. The demand side is driven by developers creating software that runs on the grid, system integrators creating solutions for enterprise and this demand side is exponentially growing for data processing and storage use cases.
+
+### Network Wall (future)
+
+see [Network Wall](network_wall)
+    
+## Roadmap 
+
+Above described Web Gateway is for 2.0.
+
+For 3.0 we start with a HTTP(S) proxy over Planetary network connection. Not all features from WebGW 2.0 have been ported.
+
+Further future, we envisage support for many other protocols: sql, redis, udp,  ...
+
+!!!def alias:web_gw,zos_web_gateway
+
+!!!include:zos_toc
+

_archive/technology/primitives/network/webgw3.md

@@ -0,0 +1,50 @@
+<h1> WebGW 2.0 </h1>
+
+<h2>Table of Contents</h2>
+
+- [Introduction](#introduction)
+- [Implementation](#implementation)
+- [Security](#security)
+- [Redundant Network Connection](#redundant-network-connection)
+- [Unlimited Scale](#unlimited-scale)
+
+***
+
+## Introduction
+
+The Web Gateway is a mechanism to connect the private networks to the open Internet, in such a way that there is no direct connection between internet and the secure workloads running in the ZMachines.
+
+![](img/webgateway.jpg)
+
+
+- Separation between where compute workloads are and where services are exposed.
+- Redundant
+    - Each app can be exposed on multiple webgateways at once.
+- Support for many interfaces...
+- Helps resolve shortage of IPv4 addresses
+
+## Implementation
+
+Some 3nodes supports gateway functionality (configured by the farmers). A 3node with gateway config can then accept gateway workloads and then forward traffic to ZMachines that only has yggdrasil (planetary network) or Ipv6 addresses.
+
+The gateway workloads consists of a name (prefix) that need to be reserved on the block chain first. Then the list of backend IPs. There are other flags that can be set to control automatic TLS (please check terraform documentations for the exact details of a reservation)
+
+Once the 3node receives this workloads, the network configure proxy for this name and the yggdrasil ips.
+
+## Security
+
+ZMachines has to have an yggdrasil IP or any other IPv6 (also IPv4 are accepted) but it means that any person who is connected to the yggdrasil network, can also reach the ZMachine without the need for a proxy.
+
+So ti's up to the ZMachine owner/maintainer to make sure it is secured and only have the required ports open.
+
+## Redundant Network Connection
+
+![](img/redundant_net.jpg)
+
+
+## Unlimited Scale
+
+![](img/webgw_scaling.jpg)
+
+
+The network architecture is a pure scale-out network system, it can scale to unlimited size, there is simply no bottleneck. Network "supply" is created by network farmers, and network "demand" is done by TF Grid users.  Supply and demand scale independently, for supply there can be unlimited network farmers providing the web gateways on their own 3nodes and unlimited compute farmers providing 3nodes for compute and storage. The demand side is driven by developers creating software that runs on the grid, system integrators creating solutions for enterprise and this demand side is exponentially growing for data processing and storage use cases.

_archive/technology/primitives/network/znet.md

@@ -0,0 +1,39 @@
+<h1> ZNET </h1>
+
+<h2>Table of Contents</h2>
+
+- [Introduction](#introduction)
+- [Secure mesh overlay network (peer2peer)](#secure-mesh-overlay-network-peer2peer)
+- [Redundancy](#redundancy)
+- [Interfaces in Zero-OS](#interfaces-in-zero-os)
+
+***
+
+## Introduction
+
+Decentralized networking platform allowing any compute and storage workload  to be connected together on a private (overlay) network and exposed to the existing internet network. The Peer2Peer network platform allows any workload  to be connected over secure encrypted networks which will look for the shortest path between the nodes.
+
+![](img/zos_network_overlay.jpg)
+
+## Secure mesh overlay network (peer2peer)
+
+Z_NET is the foundation of any architecture running on the TF Grid.  It can be seen as a virtual private datacenter and the network allows all of the *N* containers to connected to all of the *(N-1)* other containers. Any network connection is a secure network connection between your containers and creates  peer 2 peer network between containers. 
+
+![](img/overlay_net1.jpg)
+
+No connection is made with the internet.The ZNet is a single tenant network and by default not connected to the public internet.  Everything stays private. For connecting to the public internet a Web Gateway is included in the product to allows for public access if and when required.
+
+## Redundancy
+
+As integrated with [WebGW](./webgw3.md):
+
+![](img/znet_redundancy.jpg)
+
+- Any app can get (securely) connected to the internet by any chosen IP address made available by ThreeFold network farmers through WebGW.
+- An app can be connected to multiple web gateways at once, the DNS round robin principle will provide load balancing and redundancy.
+- An easy clustering mechanism where web gateways and nodes can be lost and the public service will still be up and running.
+- Easy maintenance. When containers are moved or re-created the same end user connection can be reused as that connection is terminated on the Web Gateway. The moved or newly created Web Gateway will recreate the socket to the Web Gateway and receive inbound traffic.
+
+## Interfaces in Zero-OS
+
+![](img/znet_znic1.jpg)

_archive/technology/primitives/network/znic.md

@@ -0,0 +1,24 @@
+<h1> ZNIC </h1>
+
+<h2>Table of Contents</h2>
+
+- [Introduction](#introduction)
+- [Use Cases](#use-cases)
+- [Overview](#overview)
+
+***
+
+## Introduction
+
+ZNIC is the network interface which is connected to Z_Machine.
+
+## Use Cases
+
+Can be implemented as interface to
+
+- planetary_network.
+- public ip address on a Zero-OS.
+
+## Overview
+
+![](img/znet_znic.jpg)