ok-dmr / ok-dmr-master Goto Github PK

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

• Podpora pro Hytera LP (Location Protocol, především "Triggered Location Reporting Service" a "Emergency Location Reporting Service")
• Podpora pro Motorola/MOTOTRBO LRRP (Location Request Response Protocol)
• Podpora pro ETSI LIP (Location Information Protocol)
• Možnost konfigurovat APRS handler (master nebude odesílat, ale jen zpracovávat, handler bude příp. ukládat a odesílat na public APRS)
• Možnost konfigurovat blacklist/whitelist pro public APRS reporting (pravděpodobně jako součást modulu řešícího APRS handler, ne interně v masteru)

1. Nahradit stávající closed-source řešení otevřenou implementací
2. Podporovat přímo jen nutné protokoly (homebrew)
3. Vytvořit decentralizovanou síť master serverů s inteligentním routingem
4. Umožnit rozšiřovat možnosti sítě pomocí vlastních pluginů a skriptů (podpora protokolů, zacházení s APRS/gps, motorola ARS, hytera RRS, atp.)

Chceme aby core podporoval tyto protokoly

1. Homebrew (MMDVMHost) pro přímé připojení malých i velkých systémů
2. Hytera Multi-Site Connect (přímo nebo pomocí https://github.com/smarek/Hytera_Homebrew_Bridge )
3. FastForward (P2P) pro spojení mezi instancemi master serverů

Rozhodně nechceme podporovat přímé spojení těmito protokoly

• XLX

• YSF

• OpenBridge/IPSC2

• P25

• DV4Mini

• WinMaster

• SmartPTT

• CBridge

• D-Star
  Tyto protokoly by měly být řešeny samostatnými pluginy/bridge, které budou konvertovat nepodporovaný protokol do jednoho z podporovaných (typicky homebrew)

• Homebrew client support

• MMDVM client support

• P2P Protocol support