The IP over ATM Mailing List Archive by date

[shuenn@swdc.stratus.com (Shuenn Hwang)]

Have people consider using PPP's Multilink protocol to provide
resilient ATM? The MLP gives you redundent link plus load sharing.
There may be some overheads of using it, but it might worth
considering it.

thanks,
-shuenn hwang
shuenn@swdc.stratus.com
> 
> 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
>