John D. Hays wrote:
> 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
>> [email protected] <mailto:nate%40natetech.com>
>>
>> facebook.com/denverpilot
>> twitter.com/denverpilot
>>
>>
>>
>>
>>
>
>
>
