Hi Robbie -- some comments inline.
On Mar 9, 2010, at 1:26 PM, Robbie De Lise wrote:
Hi,
We have been thinking about some new dstar system too.
We had the following idear:
1. Use a VPN network with multiple (failover) servers to connect to,
linked together, geographically spread out. This enables us to
create a private network on top of the internet or any other network
medium that can encapsulate the VPN. We think about using OpenVPN.
I have thought about and do not see a great value in a VPN and it adds
quite a bit of complexity for the general repeater operator. I do
think there are some cases where a VPN would be valuable, for example
if you are building a lot of services and repeaters all wanting to
talk to each other as a "cloud" behind a D-STAR router node -- you
could use Multicast addresses (224.x.x.x - 239.x.x.x) within the VPN
to implement a subscriber/listener architecture and not send duplicate
PTP packets between the various services and repeaters, thus lowering
overall network traffic.
2. Ip addresses. Every repeater gets a subnet inside the 10/8
network, this can be organised as the 44/8 was. Maybe we can even
use the 44/8 instead of 10/8 to not interfere with existing networks
inside a 10/8
This is where I think the Icom implementation added an unnecessary
feature. D-STAR protocol has its own useable address space in the
callsign fields of the header. In DV mode there is no reason to
assign a callsign an IP address (nor in DD mode either, really). What
I am thinking is we need a D-STAR protocol router and only when the D-
STAR protocol needs to be "tunneled" through the Internet is there a
need for the D-STAR routers to be able to locate one another and
Secure Dynamic DNS would provide that service. Also D-STAR routers
could use a variety of transports besides IPv4 to "tunnel" the D-STAR
protocol over other networks.
DD encapsulates Ethernet (not IP, though Ethernet can encapsulate IP).
Directing the packets over the Internet should be based on the D-STAR
router (there's only 1 bit difference in the header) directing the
packets based on Callsigns. If people want to build IP networks
inside DD (or Ethertalk, XNS, DecNet, ...) then they use the address
space that makes sense to them including both private address space
(10.x.x.x, 172.16.x.x - 172.31.x.x, or 192.168.x.x) and public address
space (44.x.x.x, etc.)
Part of the reason the Icom address space does not use subnets is for
the mobile terminal. A properly built D-STAR router could keep up
with the mobile terminal in the D-STAR address space (using last heard
nodes) and the underlying DD Ethernet based protocol address space
would not have to change.
3 Authentication; Radio users do not authenticate, since as you
stated, the callsign is send in cleartext and can be forged by a
"pirate. A user entering the network via RF is thus always trusted.
Systems linked over the internet, must connect to the VPN. To do
this you need a valid certificate. This certificate has to be
requested at a central (or multiple) location who verify that you
have a valid license. With this certificate a repeater or DV-dongle
user can connect to the network. This is the 'trust'.
The Secure Dynamic DNS would also use a certificate or similar token
to allow "gateway" and similar services to update IP addresses/
canonical names on the DNS. Revoke the certificate or token and
delete the record and you have accomplished the same thing. D-STAR
routers could check incoming traffic against the CALLSIGN to DNS to
IPADDRESS relationship and if it does not match, reject the traffic.
This should be more than sufficient for AMATEUR networks.
DV-Dongles should use strong authentication into a server that looks
like any other D-STAR router on the network. Once authenticated, they
run through the D-STAR routers just like anything else.
4. Multiple (failover) DNS servers linked together, geographically
spread out, who map callsigns and reflector calls to an IP address
within the subnet of the repeater. The repeaters send updates to
these dns servers with the most recent ip adres of the station. (low
TTL)
The DNS servers can easily be redundant but if you are running D-STAR
routers, the DNS really is only for the D-STAR routers to find each
other -- radios don't need IP addresses and thus would not need to be
in the DNS at all.
5. Routing between the repeaters should be done like a BGP system,
the repeater anounces its subnet to the network and the rest of the
network automagicly knows how to reach it. this can even use the
real BGP protocols. This also allows using other networks as 10/8 as
long as they are unique inside the network. (eg in a special case
you could use a subnet inside 192.168 or 172
See bullet 2
6. Callsign routing; whenever you put a callsign in UR, the system
looks up the IP address of the other station and determines how to
route to the repeater that has this callsign. Then it sends its DV
stream to that repeater.
See bullet 2 - Radios don't need IP addresses, the D-STAR router
locates the last know D-STAR router for a callsign and using an
Internet "tunnel" sends the traffic from router to router, with the
end router sending it to the callsign.
7. compatibility to the old network (trust servers) can be done by
having 1 (or multiple regionally) public IP that acts like a classic
G2 with multiple repeaters.
Yes there needs to be a bridge, but as long as G2 requires user
registration it will be limited.
8. instead of having a lot of different reflector servers the
network has a system comparable to IRC: You have a small network of
IRC servers that contain Channels. In the dstar variant we would
have linked reflector 'hubs' that contain 'channels' (the classic
reflectors). Everybody can register a reflector, but if it hasn't
been used for xxx days it might expire. These reflectors can also be
'made' on the fly, without any setup needed, and can be perfect for
temporary use.
Very similar to what I am thinking.
9. local networks (in belgium, most repeaters are linked via a 5ghz
wifi network) should run their local vpn server/reflector hub linked
to the rest of the vpn so that if there is a disaster and internet
gets disconnected, the system is able to run locally as long as the
local network still works.
That is one implementation
10. the software that does all this should also be able, next to
talking to an ICOM repeater, to also talk to a GSMK node adapter so
that its easy to setup a new repeater.
Without question - I have a GMSK node adapter and have used Jonathan
Naylor's software to create a repeater. RP2C integration is
understood now, so interfaces can been made to all of the above,
including simplex nodes.
11. Everything should be lightweight so that it can be run on low-
power pc's (like an PCEngines Alix 800Mhz 128Mb PC)
This is enhanced by keeping components small, modular, and replaceable.
12. Distro should be free to choose. Debian, Gentoo, Centos,
Mandrake, Ubuntu, whatever, ...
The architecture should be OS agnostic.
13. Everything has to be CLI based.
Everything should have a CLI interface, GUI can be added as an adjunct
to the command line for those who want it, but the D-STAR router and
tools should not require a GUI.
these are just our ideas. If you are serious about developing
something like you say, I think we best startup some sort of
workgroup and combine the best ideas. We really like the VPN idea as
it offers natural authentication that is proven to work. The
(open)VPN setup can be implemented in the software.
We can discuss the pros and cons of VPN further - I do have concerns
for the non-network savvy operator having an overly complex system.
Our preffered language would be Java. I see in your code snipped
that you prefer this too.
Let me (us) know what you think.
Code preference is up to the developer as long as we have a well
defined architecture with well defined interfaces, may the best
implementation win : ) !
73s
Robbie ON4SAX
John D. Hays
Amateur Radio Station K7VE
PO Box 1223
Edmonds, WA 98020-1223 VOIP/SIP: j...@hays.org
Email: j...@hays.org
