Skip to content

Addressing

Jump to bottom
dario edited this page Apr 2, 2017 · 26 revisions

Introduction

Communication between Souliss nodes is based on vNet a transport protocol that allow the handling of multiple communication interface and the routing and bridging between them, so each node has one or more addresses according to the table below

Media Range Start Range End
M1 – UDP/IP 0x0000 0x00FF
M1 – UDP/IP in User Mode 0x0100 0x64FF
M2 - 2.4 GHz IEEE 802.15.4 0x6500 0xAAFF
M3 – UDP/IP Broadcast 0xAB00 0xBBFF
M4 – Not Used 0xBC00 0xCCFF
M5 – USART 0xCE00 0xDFFF
Address Description
0xFF01 - 0xFCFF Multicast address
0xFDFF Broadcast (that cannot be re-broadcasted)
0xFEFF Broadcast (that has been re-broadcasted)
0xFFFF Broadcast (that can be re-broadcasted)

Each node can have one or multiple vNet address, Ethernet/WiFi nodes has additionally an IP address. The vNet protocol itself can be transported in UDP/IP frames, but has an its own addressing scheme.

Set a vNet address is simple as adding the following line of code in the setup() of your sketch, that line shall be included once for each vNet address that shall be assigned to a node.

SetAddress(address,subnet, supernode);

Nodes with multiple vNet address has multiple communication interface, details on the supported network architectures can give a better overview of the features provided by the networking layer of Souliss.

Examples of possible network configuration with the scope of extending the listening range of a wireless radio or providing routing between different communication interfaces (e.g.: Ethernet and RS485) are available.

Nodes with Ethernet/WiFi Connectivity

Nodes with Ethernet or WiFi connectivity has one or more vNet addresses as well as an IP address and the relevant configuration, there are two configuration available for this case:

  • M1 - IP Unicast vNet Address bonded with the IP Address
  • M3 - IP Broadcast vNet Address not bonded with the IP Address

Using the M1 vNet interface result into a vNet address that equals the last byte of the IP address, all nodes are always assumed to be in the same broadcast domain with subnet mask 255.255.255.0, the result is a full relation between the two address. A node, starting from the vNet address on M1 is able to compute the IP address and start an unicast communication based on UDP/IP that will carry vNet as payload.

Using the M3 vNet interface result into a vNet address that isn't related to the IP address, in this case the nodes use a broadcast UDP/IP communication. The communication is in unicast on the vNet transportation, because each vNet frame has its own addresses.

In the possible configuration scenario you will always have at least one node on M1 used to communicate with the user interfaces and other nodes that can be either on M1 or M3. Generally once configured an IP address, the framework setup automatically the relevant M1 interface.

Use of Ethernet nodes with Static IP Address (M1)

The SetIPAddress assign both IP address and vNet one for Media 1, so that with a single line of code the node is completely configured from the vNet point of view.

// Define the network configuration according to your router settings
uint8_t ip_address[4]  = {192, 168, 1, 77};
uint8_t subnet_mask[4] = {255, 255, 255, 0};
uint8_t ip_gateway[4]  = {192, 168, 1, 1};
#define myvNet_address  ip_address[3]       // The last byte of the IP address (77) is also the vNet address

void setup()
{   
    ...

     // Set network parameters
    SetIPAddress(ip_address, subnet_mask, ip_gateway);
    SetAsGateway(myvNet_address);   
}

In this example the node is also a Gateway and the vNet address (myvNet_address match the last (it's the third, because array starts from zero) byte of the IP address) is passed.

Use of Ethernet nodes Dynamic IP Address (M1)

Some transceiver allows the use of DHCP to dynamically get an IP address, refer to the table below to identify devices that support this feature. If supported, you do not longer need to specify an IP address, but

void setup()
{   
    ...
     // Get the address from the DHCP server (generally your router)
    GetIPAddress();
    SetAsGateway(myvNet_dhcp);   
}

As a general note, SoulissApp is able to detect automatically the Gateway and so you don't need to insert manually the IP address, is enough to start SoulissApp without an IP address and this will trigger the automatic detection. On some Android phones this may not work, so you are required to identify your node using an external application, like Fing that shows all the nodes on the network and then set manually the IP address in SoulissApp.

Transceiver DHCP Configuration Option Remarks
W5x00 In software conf/Webhook.h -
ESP8266 Embedded Stack - -
ENC28J60 - - uIP stack, no support for DHCP
MRF24 - - uIP stack, no support for DHCP

Arduino Ethernet Library compatibility mode (ATmega AVR only)

Souliss doesn't use the standard Arduino Ethernet Library for several reasons, but for compatibility is offered the opportunity to run the methods from the Arduino Ethernet Library inside Souliss based sketches. This works only for the Ethernet controller Wiznet W5100/W5200/W5500, but isn't supported for Ethernet or WiFi transceiver based on uIP (Microchip ENC28J60 and MRF24WB0MA) and other IP devices not using Wiznet transceivers.

Start the compatibility mode require to include #include "conf/Webhook.h" as configuration parameter, once done is expected that all library based on Arduino Ethernet Library can work directly, just consider that the IP stack is setup by Souliss itself and you don't need to use those methods.

Have care, the Arduino Ethernet library support software based DHCP and DNS for AVR, those require large amount of RAM and FLASH.

Define a MAC Address

Based on the transceiver, there are three possible option for the MAC address as per below list:

  • Locally Administered MAC Address, these address are for local use and are configured in Souliss by default with the AUTO_MAC option in ethUsrCfg.h. In this case the node use a unique local address within you network, based on the received IP address.
  • MAC Address defined in the transceiver, if the transceiver has a MAC address burned in by the factory that address is used.
  • Manual Defined MAC Address, disabling AUTO_MAC allow the user to insert its own MAC address.

As example of MAC address defined inSketch

#define MAC_INSKETCH
uint8_t MAC_ADDRESS[] = {0x1A, 0xA6, 0x49, 0x6B, 0x00, 0x01};

...

#include "Souliss.h"

setup()
{
   ...
}

An example of nodes with multiple address

Gateway Node configured with Static IP and Wireless RF interface

// Define the network configuration according to your router settings
uint8_t ip_address[4]  = {192, 168, 1, 77};
uint8_t subnet_mask[4] = {255, 255, 255, 0};
uint8_t ip_gateway[4]  = {192, 168, 1, 1};

// Set network IP parameters
Souliss_SetIPAddress(ip_address, subnet_mask, ip_gateway);
SetAsGateway(77);  // Use the last byte of the IP address if using a static IP address

Souliss_SetAddress(0x6501, 0xFF00, 0x0000);

Peer Node configured with Wireless RF interface

// Set network IP parameters
Souliss_SetAddress(0x6502, 0xFF00, 0x6501);

Gateway Node configured with IP Unicast and IP Broadcast

This is generally useful when a peer-to-peer communication between Ethernet/WiFi nodes is required but the IP addresses are not defined in the sketch, like in case of DHCP. Using a vNet address that is not bonded to the IP one gives flexibility. This is not enabled by default and need the configuration file #include "conf/IPBroadcast.h".

// Define the network configuration according to your router settings
uint8_t ip_address[4]  = {192, 168, 1, 77};
uint8_t subnet_mask[4] = {255, 255, 255, 0};
uint8_t ip_gateway[4]  = {192, 168, 1, 1};

// Set network IP parameters
Souliss_SetIPAddress(ip_address, subnet_mask, ip_gateway);
SetAsGateway(77);  // Use the last byte of the IP address if using a static IP address

Souliss_SetAddress(0xAB01, 0xFF00, 0x0000);

Network Configuration Rules

Bridging and routing facility are provided assuming the use of simple network configuration rules, these allow a node to identify how bridge or route a message and if these actions are required without additional configuration.

Addressing Rules

The addressing rules used for vNet are mainly the same of IPv4 with one difference, the length of the address. In vNet are used only two bytes (instead of 4 bytes as in IPv4).

Furthermore, in vNet the addresses are split by media, this make easy identify which media has to be used for the communication. Each media has an associated subnet mask, using a bit-wise AND between address and subnet mask, is obtained the subnet of the device. The subnet mask is fixed for M1 medias as 0x0000 and is user configurable for others, using 0xFF00 as default. Some configuration may request fixed subnet mask.

Routing and Bridging Rules

Each communication interface has an its own subnet mask and is part of the relevant subnet. A bit-wise AND operation between the address and the subnet mask give the subnet address.

Device within the same subnet must be in listening range, the concept of listening range should be referred to the communication media that are used for the device. As instance, for device that use wireless communication a listening range is the area where the radio are able to send and receive message; for device that use a wired or wireless Ethernet a listening range is the switched/routed LAN network and the bridging is not requested.

A frame that has a destination out of the own subnet, is sent to a device with routing and/or bridging capability. In this case this device is called Super Node (different from the IP Gateway) that will bridge or route the message. In the configuration of each node is specified the own Super Node address.

A device compiled as Super Node is able to route and/or bridge frames without additional configurations, the output path for a routed or bridged frame is evaluated assuming the followings:

  • All devices share the same subnet mask,
  • Each subnet has a Super Node with address “subn & 0x0001”.

If these requirement are not meet, the routing and bridging tables allow frame routing via preferred paths or not standard addressing, these are configured into routing and bridging tables.

IP Based vNet and Standard TCP/IP Connections

The vNet IP connectivity is based on UDP/IP frames using port 230 (in/out) and 23000 (out to User Mode devices) and cannot be used for other communications. In vNet are available API for bulding standard TCP/IP connection external to the vNet layer it self.

In case of software IP stack for each new connection is required an additional handler.

Address Translation

The address translation is carried out in the vNet layer when the used communication interface has addressing rules that doesn't allow a direct use of the vNet address into the interface.

In the actual release of vNet an address translation is provided for IPv4 based devices that require a 4 byte address instead of the 2 byte address of vNet. From a math point of view, this translation cannot be unique, so some bytes should be forced using a “Base IP Address”. The IPv4 address is obtained with a bit-wise adding of the “Base IP Address” and the vNet address. Due to the address translation, IP based vNet frames couldn't go out of their own IP Subnet via IP routing or NATting.

An additional address translation mode called “User Mode” is available for devices that require operation behind a NAT, the “User Mode” is build for user interfaces that shall access the vNet network from the internet and not only the home network LAN. When using the “User Mode” the IP address is saved for next communication, this mode require a first connection from the user interface to the board in order to allow the IP address recording, is not allowed the use of “User Mode” between the boards because doesn't allow a full peer-to-peer.

Clone this wiki locally