1. Introduction
This document introduces connectivity for both the edge nodes and the deployed applications on edge nodes. The connectivity purpose is to serve the application instances deployed on the edge nodes and provide network connectivity for the edge node runtime to ZedControl. The edge node run time is the Edge Virtualization Engine (EVE-OS). There is some overlap and sharing between the application connectivity and device connectivity, but it is helpful to think of them separately. Click here to know more details about the EVE-OS architecture and connectivities.
The following illustration shows the possible ways for applications to get connected with different network instance types. Here the wind sensors can use the Audio port. Serial cards, USB ports, and GPU can also be used for other applications such as pressure sensors and the Ethernet ports that connect to the Enterprise network.
- Direct Attach–The application is given the Ethernet Interface's control so that no other app can use this interface. Starting from release 8.12.0, NVME storage drives can be passed as direct-attach to application instances.
- Port sharing–Both local and switch network instances use one port.
- Local (L3 network)–EVE-OS assigns the IP address to the application connected to the network instances in a natted environment.
- Local (L2 network)–with airgap network instances, the applications can talk to each other but can't talk to the external world. If a port is not specified for a 'local network instance,' it becomes an airgap network instance.
- Switch–Any port attached to the switch network instance is exclusive to that particular network instance and cannot be shared with any other network instance irrespective of its type.
More details are discussed in the following sections.
2. Edge Node Network
The edge node services need to reach ZedControl since all the device's management and operation are performed via ZedControl. This requires at least one network port with connectivity to ZedControl for HTTPS traffic; we call such a port a management port. It is possible to configure multiple network ports for redundancy. For example, an Ethernet port and an LTE modem port. In such cases, it is possible to specify a simple priority scheme to have the LTE port (metered network) be fallback, i.e., only be used should the connectivity over the Ethernet port (free networks) fail.
These ports use DHCP to configure themselves in the simplest configuration, but it is also possible to provide static IP configuration and/or HTTPS proxy configuration. The latter includes configuring a trusted HTTPS proxy or Deep Content Inspection (DCI) performing the content inspection. From the perspective of how it operates with the TLS protocol, the proxy server performs an action that makes it a man in the middle from a TLS perspective.
Note: The proxy server is not just used for content inspection (man in the middle). Content inspection is one of the rare cases proxy server is used for.
The following scenarios differentiate between TLS tunnel for content inspection and non-content inspection:
- Content inspection–here first TLS tunnel terminates at the proxy server, and the second terminates at the ZedControl. The edge node (EVE-OS in specific) is configured with a proxy certificate and communicates with the proxy server's IP address. The proxy server does the content inspection for non-encrypted data only.
- Non-content inspection–the TLS tunnel goes from end to end from the edge node to ZedControl, but the TCP terminates at the proxy.
Data inspection is done in both directions from the edge node to ZedControl and from ZedControl to the edge node. However, sensitive data comes only from ZedControl to the edge node. Some examples of sensitive data are user credentials, data store credentials, WiFi credentials. The following illustration shows data from ZedControl getting blocked, as the proxy server finds that the data inspected does not comply with the content agreement.
3. Edge Application Instance Network
Most applications require TCP/IP connectivity towards the Internet, i.e., similar requirements that the edge node needs to communicate with ZedControl. The management port(s) can be used for that purpose, or the applications can configure separate network ports. Some applications require Ethernet or TCP/IP connectivity to the local environment, for instance, to access IIoT devices on a shop-floor network or resources on a local enterprise network.
In some cases, sensors and actuators need to be connected directly to the edge node, using audio, USB, or serial ports. And some applications need access to resources like GPU devices. Multiple applications on the same edge node might need to communicate while isolated from the external and the Internet. And suppose some applications desire to be part of a VPC/VNET in the cloud. In that case, it is beneficial to keep that VPC/VNET configuration external to the application since reusing the identical application configuration used should the application be deployed on the cloud.
As we can see from the above brief requirements, the application connectivity needs are quite diverse. We address those needs using two high-level concepts:
- Direct attachment–when an application should own a particular port, such as an audio or serial port or a WiFi radio. Such ownership implies that no other application or edge node services can use that port.
- Network instances–a way to describe a local virtual switch with different forms of external connectivity. The network instances can share the physical ports among each other and also with the edge node services.
The network instances come in different types with different properties:
- Local network instance–provides IP connectivity between all of the applications attached to it, including IP address management, DHCP, and DNS services. If a local network instance is associated with one or more network ports on the device, external connectivity uses a NAT.
-
Switch network instance–provides Ethernet connectivity between all the applications attached to it, with no IPAM. External connectivity is done using Ethernet bridging if a switch network instance is associated with a network port on the device.
Note: Once the Edge Node boots with an edge application instance, DHCP assigns the IP address. If a static IP address is defined in the cloud-init, then the DHCP IP address is changed to the static IP address. However, ZedControl would still report the DHCP IP address.
- Cloud network instance–A network instance that, like the local network instance, provides IP connectivity, including IPAM between the attached applications on the device. Still, the external connectivity uses VPN to a cloud provider or other IPsec VPN endpoint.
