Design Note: Need to think about multi-network systems in the media layer and transport layer

[thirtytwobits]

This isn't immediately important. I'm okay with starting with a 1.0 that does not properly support multiple networks though we should watch for places where we might be inhibiting them. Also note that this is not an issue for redundant connections as such connections should be supported in libcyphal for CAN and should be handled by lower layers for UDP (see 802.1 CB). One exception to the latter will be support for 10baseT1S multi-drop but this solution can borrow from our CAN transport design given that the two technologies are quite similar. Indeed, this is probably easily supportable using libcyphal::transport::redundant and some minor modifications to the udp media layer.

It's unclear how a future evolution of libcyphal will support multiple networks with either a mix of CAN and Ethernet, with only one transport type but multiple interfaces, or with a mix of both. This issue will record a discussion for future design work.

Mixed Transports

The problem of mixed media could be punted by saying that libcyphal does not intend to support multiple networks at once but can work by instantiating the library in multiple threads/tasks/processes where each instance used a different transport. Indeed, this area is undefined by the Cyphal specification and the maintainers have discussed solutions involving transporting Cyphal on top of other protocols as a possible recommendation. This would fix Cyphal as a point-to-point or point-to-bus protocol only that did not address routing functions between networks.

Single Transport, Multiple Networks

There are a few ways to look at configurations including multiple networks. One is to consider heterogeneous redundancy which might "just work™" if the latencies aren't too great between the two. Another is more likely and is clearly not considered in the current design: different networks for different nodes. This is almost a routing problem except one could draw the line at bridging and only specify support for segmentation. That is, we might support systems where a map of node identifiers to networks is used when selecting the appropriate endpoint for publication, multi-plexing subscriptions, and tracking RPC transactions. This means NodeID becomes multi-keyed to be NodeID+networkID.

[pavel-kirienko]

The problem of homogeneous and heterogeneous redundant transports is discussed in the specification; there is an implementation in PyCyphal; and a concrete design for LibCyphal is proposed in its design document.

1. Specification:

2. PyCyphal implementation and related technical notes: https://pycyphal.readthedocs.io/en/stable/api/pycyphal.transport.redundant.html

3. Homo- and heterogeneous redundancy is discussed in several places in the LibCyphal design document: https://github.com/OpenCyphal-Garage/libcyphal/blob/main/docs/design/readme.md#heterogeneous-redundancy. It is already designed into the current architecture, only the implementation is missing, which is rather easy to add -- this only calls for the addition of a new namespace libcyphal::transport::redundant next to CAN and UDP, without nontrivial changes to them.

[pavel-kirienko]

I should add that PyCyphal currently does not allow aggregating cyclic-TID and monotonic-TID transfers into the same redundant group. We discussed a while ago that this restriction has to be eliminated; this is an easy change that can be evaluated based on PyCyphal first, if there is interest.