The IP over ATM Mailing List Archive by date

[gja@thumper.bellcore.com]

[I wrote...]

>>I don't think Craig's implementation needs our concern. It will work
>>fine as the current rfc stands, or with Mark's likely new version.

[Fong replied...]

>>	But craig's implementation prompted a serious interoperability
>>	problem.  In craig's implementation, the other side was not	
>>	informed that IP packets are not allowed on the arp connection.
>>	So, it will send its IP traffic over that connection (assume the 
>>	server reply with ARP_RESPONSE and cached client's IP address.  
>>	Unless you want arp server to alwasy use 
>>	different IP address which is less preferred.

The ARP Server entity only has an ATM address, not an IP address.

A co-resident IP router entity might have an IP address, and share
the ARP Server's ATM address, but the ARP Server itself is not
associated with an IP address per se. So, Craig's implementation
has the ARP Server and IP router at different ATM addresses.
Although physically co-resident, from the perspective of other
hosts on the LIS it is not unlike a completely separate ARP Server
and IP router.

>>	The new IP connection sets up by Craig's implementation may not 
>>	be used by the other end to send its IP traffic.  Can you explain why
>>	it would if you think so ?

An arbitrary host on the LIS would only send IP traffic on a VC to the
ARP Server if it had previously resolved the destination IP address
to the same ATM address as the ARP Server (and said "hey, I already have a
VC to that destination, lets use it!"). With Craig's model no host will ever
draw that conclusion, so there is no problem.

regards,
gja