The IP over ATM Mailing List Archive by date

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



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

Resilient ATM

  • From: Andrew Smith <asmith@Baynetworks.COM>
  • Date: Tue, 30 May 95 17:40:57 PDT


> From atmpost@matmos.hpl.hp.com Fri May 19 09:07:34 1995
> From: "Gerhold, Mark L [TR]" <MLG2@trpo6.Tredydev.Unisys.com>
> To: bryang <bryang@eng.adaptec.com>, ip-atm <ip-atm@matmos.hpl.hp.com>
> Cc: rae1 <rae1@PO5.RV.unisys.com>
> Subject: Re:  Resilient ATM
> Date: Fri, 19 May 95 11:48:00 EDT

Mark,

> Bryan,

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

Use the "Release Cause" codes from signaling. RFC 1755 
calls out what error codes mean "hard" and "soft" teardowns.

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

In order to meet your stated goal, I would suggest two complementary
approaches:

1. Aim for good layer 2 redundancy/failover (e.g. use PNNI signalling)
     and use a simple upper layer protocol (e.g. RFC 1577)

2. Assume VCCs can come and go with poor failover mechanisms (e.g. UNI 3.x) 
     and define a more robust upper layer protocol (e.g. LAN Emulation)

If you go route 1 then don't bother enhancing RFC 1577 and you just have to wait 
a few months for a PNNI standard. If you go route 2 then you've got a lot more 
work to do on RFC 1577+ and distributed server problems.


> Mark G.
> 

Andrew


********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy Unit				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	asmith@baynetworks.com
Santa Clara, CA
********************************************************************************