[Sigtran] Re:Re: M3UA : Unexpected ASP-DOWNACK Message (Brian F. G. Bidulock)

chen.puran@zte.com.cn Wed, 20 June 2007 07:54 UTC

Return-path: <sigtran-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0v1a-0007ZO-CM; Wed, 20 Jun 2007 03:54:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0v1Z-0007Wj-5m for sigtran@ietf.org; Wed, 20 Jun 2007 03:54:45 -0400
Received: from mx2.zte.no ([202.103.147.155] helo=mx4.zte.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0v1Y-0006Dv-A0 for sigtran@ietf.org; Wed, 20 Jun 2007 03:54:45 -0400
Received: from [10.30.3.19] by 10.30.1.243 with StormMail ESMTP id 60247.1231352264; Wed, 20 Jun 2007 16:25:05 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id l5K868PG018887; Wed, 20 Jun 2007 16:06:08 +0800 (CST) (envelope-from chen.puran@zte.com.cn)
In-Reply-To: <E1HzahO-0000OT-Id@megatron.ietf.org>
To: bidulock@openss7.org
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF04FC080E.084C8727-ON48257300.00293BA9-48257300.002B3E8A@zte.com.cn>
From: chen.puran@zte.com.cn
Date: Wed, 20 Jun 2007 15:52:41 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2007-06-20 15:54:18
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
X-MAIL: mse2.zte.com.cn l5K868PG018887
X-Spam-Score: 4.4 (++++)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: sigtran@ietf.org
Subject: [Sigtran] Re:Re: M3UA : Unexpected ASP-DOWNACK Message (Brian F. G. Bidulock)
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
Errors-To: sigtran-bounces@ietf.org

thanks brain;

questionS:

1:

question one:
If the ASP receives an unexpected ASP INACTIVE Ack message, how the ASP
should to do?

the ASP should   consider itself in the ASP-INACTIVE state?

2:
 In RFC4666 SECTION 4.3.4.1.  ASP Up Procedures

<<If the ASP receives an unexpected ASP Up Ack message, the ASP should
   consider itself in the ASP-INACTIVE state.  If the ASP was not in the
   ASP-INACTIVE state, it SHOULD send an Error message and then initiate
   procedures to return itself to its previous state.>>

question Two:
if ASP in in the ASP-DOWN status,it can consider itself in the ASP-INACTIVE
state?



i think  how to deal wiht the unexpented ASPSM/ASPTM Message ,rfc466 is not
maturity.


=====================================================
Chen,

RFC 4666 Section 4.3.4.2 ASP-Down Procedure:

   ...

   At the ASP, the ASP Down Ack message received is not acknowledged.
   Layer Management is informed with an M-ASP_DOWN confirm primitive.
   If the ASP receives an ASP Down Ack without having sent an ASP Down
   message, the ASP should now consider itself to be in the ASP-DOWN
   state.

   If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state,
   the ASP should then initiate procedures to return itself to its
   previous state.

   ...

...which would pretty much consist of sending ASP Up.

This behavior was specifically design to permit what we have referred to
as the Unsolicited ASP Down Ack.  The SGP may wish to autonomously send
an Unsolicited ASP Down Ack in the event that it is experiencing an
extensive failure (e.g. local isolation from the NIF) that makes it
impossible for it to serve any AS.  This will drive all AS inactive for
the SGP and cause the ASP to reinitiate the ASP Up procedure.  If the
isolation persists, the SGP may respond to the ASP Up procedure with an
ERR("Refused - Management Blocking") response per section 4.3.4.1 ASP Up
Procedures (below) until the local fault clears.

   ...

   If for any local reason (e.g., management lockout) the SGP cannot
   respond with an ASP Up Ack message, the SGP responds to an ASP Up
   message with an Error message with the reason "Refused - Management
   Blocking".

   ...


Of course, an alternative would be to drop the SCTP association (but
this could result in significantly more message loss.)

--brian


_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran