Since our re6st networks spans multiple continents, we need our gateways in each geographical zone to be used for the nodes in that zone. Currently, if a machine with native IPv6 in japan tries to access a re6st node in japan, it will go through our Paris gateway, which leads to high latencies. The problem only exists in one direction, from exterior to re6st.

Communities will be implemented by assigning one AS sub-prefix per community. We will have to run a BGP daemon to advertise each community's gateway.

More information, progress and todo: P-VIFIB-Re6stnet.Communities

A TSN enabled re6st node should support multiple classes of traffic with different latency, jitter, and bandwidth requirements:

• General purpose traffic (ssh, sending data to Wendolin server, etc...)
• Keep-alive messages (for PLC)
• Sending each other's position (transponder, for drones)
• Safety circuit (to stop everything if something goes wrong)

To implement this multiplexing:

• each traffic class will get an IPv6 range assigned to it.
• Messages within a traffic class should not get routed to an address of another traffic class, unless there is no other way
• Ideally, we want traffic classes to be mapped to hardware RX and TX queues if possible
• Congestion should be spread equally for the transponder or keep-alive traffic class

Multicast is necessary for the transponder or keep-alive traffic classes in order not to waste network ressources.

• PIM sparse multicast should be functionnal in re6st
• With multicast we can do OPC-UA PubSub