The IP over ATM Mailing List Archive by date

["Gerhold, Mark L [TR]" <MLG2@trpo6.Tredydev.Unisys.com>]

Bryan,

>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.

Ok. However, there is a configuration where this doesn't
work. Suppose you want to build a resilient network, with
redundant NICs, switches, and servers.  In this case, the
two NICs connect to different switches.  The network
portion of the ATM addresses of the two NICs must be
different.

>
>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.

Yes, this makes sense.  My assumption is that the combination
of a dropped VCC plus a new InARP Reply from a new ATM address
is sufficient to invalidate/update the ARP entry.

I'm also hoping that there is some way to distinguish soft and
hard teardowns of VCs. F5 Alarm Indication Signal (AIS) might
do this, if implemented.

>
>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
>

I think you've defined the problem.  Layer 3 timeouts don't
meet my objective of maintaining TCP dialogs.  Obviously, some
hadware faults can or should raise alarm indications that should
trigger faster reestablihment of VCs.  And soft teardowns of VCs
should be allowed for cost reasons.

Mark G.