[Cyphal/UDP] Architectural issues caused by the dependency between the node's IP address and its identity

The saga continues:

  1. This is an optimization for UDP/IP on Ethernet. By limiting the multicast group ID to the least significant 23 bits, Ethernet hosts can avoid additional filtering responsibilities above layer 2.
  2. RFC 2365, Section 6.2.1 reserves 239.0.0.0/10 and 239.64.0.0/10 for future use (because of footnote 1, Cyphal/UDP does not have access to the 239.128.0.0/10 scope). Cyphal/UDP uses this bit to isolate IP header version 0 traffic (note that the IP header version is not, necessarily, the same as the Cyphal Header version) to the 239.0.0.0/10 scope but we can enable the 239.64.0.0/10 scope in the future.
  3. SNM (Service, Not Message): If set then this is an RPC request or response and the 16 LSbs of the destination IP address is the full-range destination node identifier. If not set then the 13 LSbs of the destination IP address are a subject identifier for a pub/sub message and the 14th and 15th, and 16th LSbs are 0.
  4. I’ve omitted the subnet concept for now. I think we should introduce that in a later change once the Cyphal/UDP specification is more mature. As such this is zero on transmit, discard on receipt unless zero.
  5. We’ll register UDP ports later. These are just an examples.
  6. Per RFC 1112, the default TTL is 1, which is unacceptable. Therefore, publishers should use the TTL value of 16 by default, which is chosen as a sensible default suitable for any intravehicular network.
  7. Reserved bits we can use for a future version of the header that supports a variable size or we can decide to do other stuff with this bits.
  8. In the future we want to propose using this bit in Cyphal/UDP and bit 23 of the Cyphal/CAN spec as a “valid data” flag in a similar manner to ARINC-825. It would mark a given transfer as containing valid data versus invalid data for a periodic signal (think GNSS where the position message is always sent at XXHz and is marked invalid until satellite fixes are adequate This allows “signal is present but not valid” logic branches in vehicle control code which is different from “signal is missing”). I’m not going to dive into this proposal right now but the TLDR is this bit must be the same for all transfers composing the same message.
  9. If the SNM10 bit is set then this is a 10-bit service identifier with a 1-bit IRNR11 flag, otherwise it is a 13-bit subject identifier.
  10. SNM (Service, Not Message). Same value as found in the destination IP header (SNM3).
  11. IRNR (Is Request Not Response) if SNM10 is set.
  12. SwST (Starts with Synchronized Time): If set then Cyphal routers can interpret the first 56 bits after the Cyphal header as a uavcan.time.SynchronizedTimestamp-1.0 field. This deep packet inspection enables custom routing rules based on time but the specific rules are not controlled by the specification.
  13. Like in CAN: 0 – highest priority, 7 – lowest priority. This data is duplicated from lower-layer QoS fields but provided in the Extended Cyphal header to simplify transfer forwarding where the QoS data is not readily available above the transport layer.
  14. IAM (Is Anonymous Message) bit is set following the same rules as Cyphal/CAN. Note that any message with both the SNM10 and IAM set is invalid.
  15. The 31 bit frame index within the current transfer.
  16. EOT (End Of Transfer): if the most significant bit (31st) bit of the 32-bit frame index is set if the current frame is the last frame of the transfer.
  17. If EOT16 is set then this is the CRC-32 of the reassembled transfer (header data excluded).