The IP over ATM Mailing List Archive by date

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

Mark,


>I have been trying to decide if a resilient ATM endsystem is
>workable, or an easy upgrade to RFC 1577.  In TCP/IP, define
>resilient ATM as preserving TCP dialogs even when there is an
>underlying hardware failure.
>
>Pitch. I see that the ARP server function has resiliency as a
>work item.  What's good for the server is good for the endsystem.
>ATM should try to compete with FDDI and allow fault tolerant
>operation of the entire network, including the endsystem.
>

I think resilient endsystems are a real good idea. A few
comments ...

I think it is possible right now, without any protocol
spec changes, to build a resilient endsystem by having
the second ATM NIC register with the same ATM address
as the first, when the first fails. The outside world will 
just see a VCC termination and reestablishment. A switch 
should detect the first link going down and not reject 
the second registration as a duplicate address.

There is a problem about associating / deriving 
layer 3 entity status from VCC status, because of
the existing specs on LLC and VCC managment.
This may be of relevance to some of the issues you raised.

You cannot necessarily deduce that anything "bad" has happened 
just because a VCC has gone away. Right now there is no 
requirement that you maintain a VCC up if you have nothing 
to send. Thus you wouldn't invalidate an ARP entry, 
for example, just because a VCC was dropped.

Also you cannot deduce that anything "good" is happening
just because a VCC is established. There may be many 
entities sharing a VCC, and your ARP server entity may
have failed for example, but the VCC could still be up
as other entities may be using the VCC. 

The only way you can deduce a positive status about a layer 3 
entity is by a response to a layer 3 packet. A negative
status can be deduced by layer 3 timeouts, or by connection
establishment failures, (not connection terminations).

This separation between layer 3 and VCC status is 
the price you pay to keep VCC usage to a minimum, on the 
premise that VCCs are "expensive".

Bryan