I think that any IP address (terminal) assigned to a DV radio is an artifact of the ID-1 networking design. I also think Icom engineering missed that DD is D-STAR Frame encapsulation of Ethernet and not TCP/IP. Certainly TCP/IP can live in the Ethernet frame, but its my belief that to be true to the D-STAR air protocol, any gateway design must support transport of any Ethernet frame that is encapsulated by a D-STAR Frame. Like so many networking transports, there are layers to the stack. The gateway should transport D-STAR frames to the gateway that currently services the DST/UR D-STAR address. I certainly don't have a problem where the use of something DNS facilitates that, but I don't like artificial dependencies and artifacts.
So lets say that Gateway 1 is at 24.22.100.19 with FQDN KX1XYZ.dstartransport.net and is servicing the following: Repeater Module KX1XYZ A Repeater Module KX1XYZ B Repeater Module W1AW (Think outside the Icom implementation, callsigns are just addresses) Radio NU1TY Radio W1ABC ... Radio KN1ZKY If we want to use DNS, we certainly can have KX1XYZ_A IN A 24.22.100.19 or IN CNAME KX1XYZ.dstartransport.net. KX1XYZ_B IN A 24.22.100.19 or IN CNAME KX1XYZ.dstartransport.net. W1AW IN A 24.22.100.19 or IN CNAME KX1XYZ.dstartransport.net. NU1TY IN A 24.22.100.19 or IN CNAME KX1XYZ.dstartransport.net. W1ABC IN A 24.22.100.19 or IN CNAME KX1XYZ.dstartransport.net. ... KN1ZKY IN A 24.22.100.19 or IN CNAME KX1XYZ.dstartransport.net. Then if KN1ZXY keys up on Gateway 2 at 188.199.200.5 with FQDN WX1XX.dstartransport.net Its record is rapidly updated to KN1ZKY IN A 188.199.200.5 or IN CNAME WX1XX.dstartransport.net. (of course you could use record types as well) This would allow traffic to be directed to either Gateway 1 (KX1XYZ) or Gateway 2 (WX1XX) by looking up the serviced callsign and routing accordingly. When an Internet packet arrives at the designated gateway via IP addressing, it extracts the D-STAR frame and directs it based on its callsign and associated port (not a meaningless IP address). If the D-STAR frame is DV, it should eventually end up a radio or other device with AMBE decoding capability, if it is DD, the DD device would extract the Ethernet packet and present it to the device's Ethernet connection. Then the DD device owner can build whatever network topoplogy they desire based on the protocol selected. (For example, a token passing bus, might be better for ID-1 throughput, than a CDMA based TCP/IP system.) Personally, I would not implement gateway address management as a TCP/IP DNS system, leave that to allow gateways (and other Internet connected D-STAR application servers) to find and communicate with one another. The address mapping can happen in dynamic structures (like a hashtable) and only use a scheme like the DNS records, to fill in when the destination gateway is not known. Nate Duehr wrote: > > > > On Jul 29, 2009, at 3:17 AM, dlake02 wrote: > > > Your comment on the 10.X.X.X range is interesting - whilst I would > > gladly sweep that away in an instance, I am concerned that there is > > a use that may break. Does anyone know what was in Icom's mind when > > they used that range ? > > > Of course, the range itself isn't the key... 10.x.x.x is a reserved > private IP range and used by lots of folks behind NAT. What's > "interesting" about it is that -- I believe... in Japan, where JARL > runs the repeaters and Gateways that they've also built a 10.x.x.x > intranet between all of them... over here, we NAT straight out to the > public IP world. I think they can manage their network from their > ID-1's over there, and connect to "other stuff" on the 10.x.x.x > network, but I can't be sure. Just rumors I've heard. > > > I always HOPED that the whole point of registering a DNS entry and > having a 10.x.x.x network address was so that the system could route > that traffic from say, and ID-1 in Denver, and someone else's ID-1 in > another city. But I don't think in the current configuration today > that it works, nor does it look like there's any plans to actually > accomplish it. > > That sure LOOKS like what they were originally intending to tackle > though, considering the entire D-STAR product was the 1.2 GHz > repeaters/radios at first ONLY... then the VHF/UHF repeaters and > cheaper radios were released. But you can see a lot of "stuff" was > originally intended for those running ID-1 rigs, and didn't translate > all that well over to the non-data-capable rigs. (High speed data, > that is.) > > These are all total guesses looking at the design in hindsight and > knowing the whole thing was designed for ID-1's and the 10 GHz links, > originally... then the Gateway and VHF/UHF came along, and are by far > the more commonly used "side" of D-STAR now. > > -- > Nate Duehr > n...@natetech.com <mailto:nate%40natetech.com> > > facebook.com/denverpilot > twitter.com/denverpilot > > > > -- John D. Hays Amateur Radio Station K7VE <http://k7ve.org> PO Box 1223 Edmonds, WA 98020-1223 VOIP/SIP: j...@hays.org <sip:j...@hays.org> Email: j...@hays.org <mailto:j...@hays.org>
