The IP over ATM Mailing List Archive by date

[bryang@eng.adaptec.com (Bryan Gleeson)]

Apologies to list veterans if this is an old topic, which
I suspect it might be ... 

Is it true to say that the only way to build a robust client is
to have it issue an ATMARP request (for an arbitrary address) 
when it first connects to the ARP server and at regular intervals 
after that to ensure the information is refreshed ? Relying on 
the InATMARPs issued by the server won't do the job due to the 
fact that the InATMARP responses may get lost. This could lead 
to a situation whereby the client believes itself to be registered 
but is, in fact, not registered. If a server does not receive a 
reply to an InATMARP request, (or set of requests if it 
implements a retry scheme), then it will delete the arp table 
entry for that client, and the client will be totally unaware 
this has happened since it will have quite happily responded 
to all the InATMARP requests it saw.

If a client receives any response to an ATMARP request 
(positive or negative) then it knows the request reached
the server and the source information in the request will
have been used to update the server's arp table. I'm
assuming that the last paragraph in 1577 section 6.3 is 
mandatory since the word "will" and not "may" is used.
(Adding robustness ...) If a client cannot connect to
the server it can start bells ringing and lights flashing
etc, but the server cannot do the same on detecting the lack
of a response to its InATMARP requests as it cannot 
discriminate between a client's normal shutdown and 
error conditions. Again I'm assuming that there are 
cases whereby the ip/atm entity could be shutdown but
the VCC stays up, as the VCC could be an LLC VCC shared by 
multiple protocols. The most appropriate entity to ensure 
that a client's information is registered is the client
not the server. 

If the ATMARP requests are necessary then the InATMARP
requests appear redundant for SVCs. If they are redundant 
can we get rid of them (neatly solving the data loss problem
due to the lack of a 3-way handshake in Q93B :-)

Bryan Gleeson
Adaptec.