(ION) Re: what's the difference between ERR_L_DROP, ERR_L_RELEASE

Grenville Armitage <gja@dnrc.bell-labs.com> Thu, 09 July 1998 03:05 UTC

Delivery-Date: Wed, 08 Jul 1998 23:05:03 -0400
Return-Path: owner-ion@sunroof.Eng.Sun.COM
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.8.5/8.8.7a) with SMTP id XAA24849 for <ietf-archive@ietf.org>; Wed, 8 Jul 1998 23:05:02 -0400 (EDT)
Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA29966; Wed, 8 Jul 1998 20:01:26 -0700
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id UAA28403; Wed, 8 Jul 1998 20:01:24 -0700
Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA15068 for ion-dist; Wed, 8 Jul 1998 19:55:48 -0700 (PDT)
Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA15061 for <ion@sunroof>; Wed, 8 Jul 1998 19:55:25 -0700 (PDT)
Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA22542 for <ion@sunroof.eng.sun.com>; Wed, 8 Jul 1998 19:55:19 -0700
Received: from maelstrom (maelstrom.nexen.com [204.249.99.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA06059 for <ion@sunroof.eng.sun.com>; Wed, 8 Jul 1998 19:55:20 -0700 (PDT)
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom (8.8.5/8.7.3) with ESMTP id WAA01234 for <ion@nexen.com>; Wed, 8 Jul 1998 22:54:07 -0400 (EDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id WAA12061 for <ion@nexen.com>; Wed, 8 Jul 1998 22:54:06 -0400 (EDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jul 8 22:53:36 EDT 1998
Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.17.249.166] (may be forged)) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA13208; Wed, 8 Jul 1998 22:53:31 -0400 (EDT)
Message-ID: <35A42FEE.5E848DA7@dnrc.bell-labs.com>
Date: Wed, 08 Jul 1998 22:50:22 -0400
From: Grenville Armitage <gja@dnrc.bell-labs.com>
Reply-To: gja@dnrc.bell-labs.com
Organization: Bell Laboratories, Lucent Technologies
X-Mailer: Mozilla 4.04 [en] (WinNT; U)
MIME-Version: 1.0
To: wanghai@NJICEATM.ICE.EDU.CN
CC: ion@nexen.com
Subject: (ION) Re: what's the difference between ERR_L_DROP, ERR_L_RELEASE
References: <357F38E6.725@NJICEATM.ICE.EDU.CN>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ion@sunroof.Eng.Sun.COM
Precedence: bulk
X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com
X-Info: Submissions to ion@sunroof.eng.sun.com
X-Info: Hypermail archive at http://netlab.ucs.indiana.edu/hypermail/ion/

Hai,

wanghai wrote:
> 
> Mr Armitage:
>  Sorry this question comes late.

that's okay. sorry my reply came late too :)

>  I review the RFC 2022 again when after the reading of IEEE paper of
> your's . a question arose here: what's the difference between ERR_L_DROP
> ,ERR_L_RELEASE?
>  in my understanding, ERR_L_DROP refer to a leaf drop at ATM layer. So
> the p-mp VC still alive,but lost a leaf.
>  ERR_L_RELEASE refer to a VC broken at ATM layer. So the P_MP VC are
> stopped immediately.
>  am I right?

Yes. ERR_L_DROP was supposed to be a subset of ERR_L_RELEASE.
In general ERR_L_RELEASE on a pt-mpt VC would indicate that
_all_ leaf nodes had dropped off (or the VC had been torn down
through some other event)

>  if then, when MARS receive a ERR_L_RELEASE on CLUSTERCONTROLVC, that
> means ClustercontrolVC are dead at that time, so some action must be
> taken instead of just discard a leaf on ClustercontrolVC.
>   from the algorithm for ERR_L_RELEASE, I found it is much proper for
> MARS receive ERR_L_DROP, that means a leaf was dead, but
> ClustercontrolVC still alive.
>   there is no action for MARS receiving ERR_L_DROP, it did not receive
> such message at all? why?
>    I think this problem is too big to be ignored. So there must be
> something I am wrong. Can you point it out for me?
> 
>                                                Hai Wang

No, actually, you are right. The text in RFC2022 around section 6.1.2
appears to have collapsed the ERR_L_DROP and ERR_L_RELEASE responses
together. Strictly speaking the last paragraph of 6.1.2 refers to
the actions taken by the MARS when it receives an ERR_L_DROP
(and indication that an individual leaf node has dropped). Receipt
of an ERR_L_RELEASE case implies all leaf nodes have been dropped
(functionally equivalent to receiving an ERR_L_DROP from each cluster
member, so the MARS would remove _all_ cluster members from its
internal database)

(In practical ATM signaling systems the functional equivalent of
ERR_L_DROP indication is a special version of ERR_L_RELEASE, which
is why no-one has noticed this before, I suspect)

cheers,
gja
________________________________________________________________________
Grenville Armitage                          High Speed Networks Research
http://nj5.injersey.com/~gja              Bell Labs, Lucent Technologies

X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with
X-Info: 'unsubscribe ion' in the body of the message.