The IP over ATM Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Resilient ATM
Here's a diversion from multicast.... 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. Here is a strawman for a redundant ATM endsystem. Endsystem configuration: One IP address. Two ATM NICs, with two ATM addresses - One active, one standby. 1. One NIC fails, or someone pulls the cable to the NIC. Detect the failure. Close all VCs from the failed NIC. 2. Move the IP address to the backup NIC. 3. From the backup NIC, initiate the VC to the ARP Server, if not already setup. 4. Transmit and respond to ARP_Requests and InARP_Requests, as in RFC 1577. 5. The remote endsystems must also close the failed VCs, invalidate the ATMARP entries, and periodically transmit ARP_Requests to the server. One obvious question with this simple scenario. How do you "detect the failure"? There are a few partial failure recognition methods. First, signaling can detect the network loss of SVCs. Second, SONET can detect the loss of a link. And third, there are F5 flows that send periodic wraparound cells on a particular VC. I'm not sure that any or all of these can detect the loss of a connection under all failure scenarios, but F5 flows offer the best hope. It's not clear that F5 flows are being universally implemented, and what happens if only one end of a VC originates F5 cells. So, to recap: Has anyone else attempted to define a resilient ATM endsystem as an addon to RFC 1577? What mechanisms will be used to detect a ATM VC failure, and to close the VCs? Mark Gerhold Unisys mlg1@ecdcsvr.tredydev.unisys.com |
|