The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-May> msg00165



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Resilient ATM

  • From: Curtis Villamizar <curtis@ans.net>
  • Date: Thu, 18 May 1995 17:13:16 -0400
  • CC: "ip-atm @" <ip-atm@matmos.hpl.hp.com>, "Erickson, Richard A [RV]" <rae1@PO5.RV.unisys.com>, Gerhold at ecdcsvr <mlg1@ecdcsvr.tredydev.unisys.com>


In message <2FBB59F6@trpo1.tr.tredydev.unisys.com>, "Gerhold, Mark L [TR]" writ
es:
> 
> 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,

As I'm sure you are aware, the easy alternate is to put your two NICs
two separate logical subnets and use IP routing to route around the
problem.  Although OSPF hello and adjacency timeout intervals are
typically set to converge in 45 seconds, you could set this to a much
smaller value.  Of course, if you want millisecond cutover this won't
work.

Curtis

PS- I'd like to bring up a related topic.

Has anyone considered implementing link quality monitoring (LQM) on a
VC?  LQM might provide feedback to indicate the the ATM "best effort"
isn't very good or just to monitor the impact on a UBR VC.  It can
also be used as a queue to routing to declare and adjacency down prior
to the hello interval expiring.

LQM has been defined for point to point interfaces.  It might be
useful to keep LQM parameters with each ARP entry for at least the
lifetime of the ARP entry (associating LQM with the ARP entry would
then apply to ethernet and FDDI as well).  The current encapsulation
would have to be changed slightly to allow LQM packets to exist as
another protocol (like ARP) or as a protocol on top of IP.