Master-Master protocol and infrastructure (routing/L2/...)

[smarek]

Getting the single-master to work should be no hard effort, however we'll need two protocols specified and possibly updated.

1st we're talking MMDVM, where there current HBLink3 protocol, is not standalone documented, and it needs to be (and possibly protocol version shall be determined directly from packets, instead of hard-coded assumptions.

2nd we need quality MASTER-MASTER infrastructure, if we want the OK-DMR-Master to provide decentralised work, where each master administrator decides about what other nodes/networks he's part of and what kind of routing his master(s) accept.

So in search of existing or effort to design new protocol, we've come to some basic requirements on its features, and we'd like to hear you (the ham/prof community), whether there is already something ready-to-use, or if you think the features shall be different

Expected/Needed Features

• Transport authentication
  • preferably each master node has it's own private/public key (PKI) and transport PDUs (or the whole network traffic) is signed (HMAC) and (optionally) encrypted
  • this shall remove the need to configure separate ssh tunnels or vpn infrastructure
  • also each master shall define which peers are authenticated and what kind of traffic is accepted from given peer (even if just range of accepted incoming DMRIDs)
• Protocol versioning
  • Big problem in current HAM sw solutions, is the protocol is not versioned, thus the implementations and further alterations to PDU contents are usually backwards-incompatible or diverge with different softwares
  • Each packet must be marked with protocol and it's version information, so we can strictly validate the contents and speed up the adoption in various software solutions
• Minimal packet size
  • probably by binary-serialization, like in protobuf (Google Protocol Buffers)
• Routing support (OSPF?)
  • This is probably the biggest challenge in de-centralised near-real-time communication design, where we want to support bridged connection (eg. master-hop-hop-master) and in resulting network graph consume as little bandwidth as possible
  • Either we can skip this expectation completely or we can limit the support of routing by removing hops (bridges/jumps)
  • However we want the resulting network to be resilient when network outages (even large ones) occur
  • Routing should be probably based on each node preferences of content Consuming (ie. TGs i'm interested in or currently temporary, on-demand, part of, because of outgoing call/ptt) and Producing (DMR IDs i declare are my own thus I can produce their content to other Consumers)

Currently we don't think OpenBridge is nowhere close to these requirements, and BM's FastForward is closed source, so if anybody knows of good protocol that (even partially) fullfills the expectations, please share with us, before we get to implement the whole protocol from scratch

[M6NBP]

Speak with Simon G7RZU

[smarek]

@M6NBP did that, the current FreeDMR is imho not good enough for my expectations, but might work at first, sure.

Also i've tried to contact py2p / p2p-project as their current state of protocol and routing is already present, and it's compatible with different programming languages, which would be great bonus, apart from documented interfaces/protocols