This is very sensible but I would prefer to avoid making TSN a hard requirement to avoid losing a significant portion of non-critical/soft-real-time/experimental systems that can tolerate the conventional IGMP multicast. So far I don’t see any problem with making the transport compatible with either TSN or traditional multicast by means of a simple switch without altering the UDP packet format.
This is not really related to CAN at all (and certainly not related to MAVLink which is a separate application-layer protocol). You may be missing this context:
- Alternative transport protocols in UAVCAN
- https://pyuavcan.readthedocs.io/en/stable/api/pyuavcan.transport.udp.html
TCP/IP is currently not leveraged by UAVCAN and there are no plans to change that at the moment.