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

"Brian F. G. Bidulock" <bidulock@openss7.org> Wed, 20 June 2007 08:49 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 1I0vsz-0001dV-C9; Wed, 20 Jun 2007 04:49:57 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vsx-0001dD-JP for sigtran@ietf.org; Wed, 20 Jun 2007 04:49:55 -0400
Received: from gw.openss7.com ([142.179.199.224]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0vsv-0002ag-64 for sigtran@ietf.org; Wed, 20 Jun 2007 04:49:55 -0400
Received: from ns.pigworks.openss7.net (IDENT:VPjK0EEC993y7BPtta87M0I8uLkQgrM/@ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id l5K8niM09676; Wed, 20 Jun 2007 02:49:44 -0600
Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id l5K8nig10571; Wed, 20 Jun 2007 02:49:44 -0600
Date: Wed, 20 Jun 2007 02:49:44 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: chen.puran@zte.com.cn
Subject: Re: [Sigtran] Re:Re: M3UA : Unexpected ASP-DOWNACK Message (Brian F. G. Bidulock)
Message-ID: <20070620024944.A10271@openss7.org>
Mail-Followup-To: chen.puran@zte.com.cn, sigtran@ietf.org
References: <E1HzahO-0000OT-Id@megatron.ietf.org> <OF04FC080E.084C8727-ON48257300.00293BA9-48257300.002B3E8A@zte.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <OF04FC080E.084C8727-ON48257300.00293BA9-48257300.002B3E8A@zte.com.cn>; from chen.puran@zte.com.cn on Wed, Jun 20, 2007 at 03:52:41PM +0800
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: sigtran@ietf.org
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: bidulock@openss7.org
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

chen.puran,

chen.puran@zte.com.cn wrote:                       (Wed, 20 Jun 2007 15:52:41)
> 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?

Read the RFC.  RFC 4666 Section 4.3.4.4 ASP Inactive Procedures

   ... 

   At the ASP, the ASP Inactive Ack message received is not
   acknowledged.  Layer Management is informed with an M-ASP_INACTIVE
   confirm primitive.  If the ASP receives an ASP Inactive Ack without
   having sent an ASP Inactive message, the ASP should now consider
   itself to be in the ASP-INACTIVE state.  If the ASP was previously in
   the ASP-ACTIVE state, the ASP should then initiate procedures to
   return itself to its previous 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?

Yes, and then "initiate procedures to return itself to its previous state":
that is, send an ASP-DOWN message.

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

Did you have a proposal for improvement?

--brian

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

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

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