Subject: Digital Radio Configuration Question

From: "Richard C. Ascheri" <[email-masked]>
Date: Mon, 17 Apr 2000 13:32:28 -0700

Hello,

I'm a Systems Engineer at Raytheon Company.  I have been working on the 
development of a digital IP based radio for some time now.  The radio has 
an Ethernet interface, PPP interface, and an ADDSI X.25 interface.

My question relates to the configuration of the radio.  To configure the 
radio we have an implementation of SNMPv2.  This implementation allows the 
radio to be configured over the Ethernet or PPP interfaces using the SNMPv2 
protocol.

My question relates to configuring the radio without knowing it's IP 
address.  I understand that SNMP requires the IP address of the device you 
want to configure.

I am interested in a standard method of announcing the IP address of the 
Ethernet interface.  This would allow a configuration tool to look for the 
announcements and then send SNMP configuration messages to modify the 
radios configuration.  For this scenario you can assume that the radio will 
be attached to a single host over an Ethernet interface.  There will be no 
other hosts or radios on the network.  Assume that the IP address of the 
radio is NOT known.  It could be set to anything, even an address outside 
of the range of the hosts subnet.

I have looked at a number of RFC's but have found these two that may work:

RFC 1256 - ICMP Router Discovery.  This rfc does announce the IP address, 
however, for this scenario I'm not interested in saying that this radio is 
the next hop gateway.  Given that the radio has numerous interfaces and an 
TCP/IP stack you might consider this a router.  However, I don't really 
feel that this RFC directly relates to solving the configuration problem. 
 The host is not really looking for it's next hop gateway.  It's looking 
for devices that can be configured through SNMP.

RFC 2608 - Service Location Protocol v2.  This rfc does imply that I could 
create a "Configuration-Service" and announce its availability using the 
SNMP protocol.  This actually sounds like the right kind of solution to my 
problem.

But now I'm wondering whether or not there is something else that I haven't 
found.  Maybe something in the works, as a draft, or a working group that 
is responsible for looking at these kinds of problems.

Any and all comments would be gratefully appreciated.

Thanks in advance.
Rick.

Richard C. Ascheri					Raytheon Company
Principle Systems Engineer				1801 Hughes Drive
Network Technology Group				Fullerton, CA.  92836
C3I Systems					http://www.raytheon.com
[email-masked]