The IP over ATM Mailing List Archive by date

[np@wipinfo.soft.net (Narayanan Prithviraj)]

Hello:

I'm not sure if I've missed out on this thread somewhere,
but I can't understand how we can get rid of INARP's and
the registration process. Consider the case where a client 
(say client A) establishes a connection to the ATMARP server, 
but does not wish to talk to any other client - in this case 
the server will receive no ARP request packets from 
client A, and so will not update its database with client A's 
entries. If another client (say client B) wants to contact
client A, it will end up receiving only ARP_NAK's from the server;
a process that would continue until client A wanted to talk to someone.

It can of course be argued that client A would not make the connection
to the server unless it wanted to contact someone else - but it
still does not solve the problem of it willing to accept incoming
connections without wanting to talk to someone.

Clarifications anyone?
prithvi.

> From laubach@terra.com21.com Fri Sep 23 03:12:15 1994
> Date: Fri, 23 Sep 1994 00:05:32 -0700 (PDT)
> From: Mark Laubach <laubach@terra.com21.com>
> Sender: Mark Laubach <laubach@terra.com21.com>
> Reply-To: Mark Laubach <laubach@terra.com21.com>
> Subject: Re: Question on RFC1577.
> To: Fong-Ching Liaw <fong@fore.com>
> Cc: gja@thumper.bellcore.comI, ip-atm@matmos.hpl.hp.com
> Mime-Version: 1.0
> Content-Type> : > TEXT/PLAIN> ; > CHARSET=US-ASCII> 
> 
> 
> > I really think we should reconsider this sequence of message
> > exchange.  Isn't it the one who initiate the call knows better
> > what packets should be sent first ? The arguments of client doesn't
> > need to know whether the other end is a server or ... doesn't seem
> > to be good enough (to me).  
> 
> I'm saving all these messages for the rewrite.  I think the best
> next alternative might be having the client, after initiating
> the LLC/SNAP VC, just sends its normal ARP_REQUESTs to the server.  
> The server then can build/check it tables as needed based on the 
> client's source information; i.e., it builds the server table by
> observation of the requests sent to it.  No IN_ARP is required 
> and the model works for unicast server and the multicast 
> service w/o changes to any existing RFC1577 clients.
> 
> > ... Imagine some other protocols 
> > uses LLC/SNAP to do non-IP and get an IN_ARP.  
> 
> The assumption was that the implementations would just discard
> the incoming packet if it didn't have support for a protocol.
> 
> > I remembered Joel cited some reason for doing so.  Can someone re-cite ?
> 
> We'd have to go back into the archives unless Joel can remember.....
> 
> Mark
> 
> 

+---------------------------------------------------------------+
| Narayanan Prithviraj            EMAIL: np@wipinfo.soft.net    |
| Communication Group, R&D        Tel:   +91-80-558-8422,ext 306|
| Wipro Infotech Ltd              Fax:   +91-80-558-6970        |
| 88, MG Road                                                   |
| Bangalore 560 001                                             |
| INDIA                                                         |
+---------------------------------------------------------------+