Subject: Re: [Sigtran] M3UA:ASPAC Procedures

From: [email-masked]
Date: Tue, 16 Dec 2003 15:25:19 +0530

Brian

 Please see the comments .

Agurmukhani,

Please see comments below...

[email-masked] wrote:
(Tue, 16 Dec 2003 09:34:41)
>
> <<<<   Both sides are exchanging ASPUP messages
>    Please have a look at the following
>
>
>       +------------+                 +-------------+
>       |   IPSP1    |                 | IPSP2       |
>       +------------+                 +-------------+
>
>       ASPUP
>       -------------->
>
>       ASPUP-ack
>       <-------------------
>
>
>                    ASPUP
>                  <-------------------
>
>            Aspup-ACK
>                 ------------>
>                ASPAC         |
>       T(ack) --------------->|
>       |                      |
>       |                      |  ASPUP
>       |<---------------------|---
>       |   (Inactive state)   |  ASPUP-ack
>       |                      |------------>
>       |                ASPAC (state->Active)
>                              |----------->
>       ASPAC-ack
>       <----------------------- state->Active
>       discarded
>       since state Inact
>
>
>         As you can see ASPUP from IPSP2 reaches IPSP1
>         when it has sent ASPAC . IPSP1 had already responded
>         with an ack which did not reach IPSP2 due to some
>         problem in network.

Cannot happen with SCTP.  If the ASPUP Ack message cannot reach
the other end, neither can the ASPAC, and the SCTP association
will fail.

The UAs were designed to run over a reliable transport, of
which SCTP is one.  What you describe is an unreliable transport.

>>>>Agreed. But consider congestion in the network as a result
   of which ASPUP-ack and Active messages are delayed. In the
   meantime, retransmission timer at IPSP2 expires and it sends
   ASPUP again.On receiving this ASPUP , IPSP1 changes the
   state of Remote AS to Inactive but does not stop timer T(ack)
   Now when Active-ack  reaches IPSP1, it is discarded.

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
[email-masked]
 https://www1.ietf.org/mailman/listinfo/sigtran

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Dec 2003 04:17:32 -0700

Agurmukhani,

[email-masked] wrote:                                                 (Tue, 16 Dec 2003 15:25:19)

-X- snip -X-
>    Now when Active-ack  reaches IPSP1, it is discarded.

RFC 3332 Section 4.3.4.1 ASP Up Procedures:

   ...

   If an ASP Up message is received and internally the remote ASP is
   already in the ASP-INACTIVE state, an ASP Up Ack message is returned
   and no further action is taken.

RFC 3332 Section 4.3.4.1.2 IPSP Considerations (ASP Up)

   An IPSP may be considered in the ASP-INACTIVE state after an ASP Up
   or ASP Up Ack has been received from it.  An IPSP can be considered
   in the ASP-DOWN state after an ASP Down or ASP Down Ack has been
   received from it. ...

also

RFC 3332 Section 4.3.4.1 ASP Up Procedures:

                                           .... The SGP MUST send an ASP
   Up Ack message in response to a received ASP Up message even if the
   ASP is already marked as ASP-INACTIVE at the SGP.

So in your example, An ASP UP Ack should be sent and no other action
taken.  So it still waits for the ASPAC Ack and is still in the
ASP-INACTIVE state.  The additional ASPUP Ack will be discarded.

That is not a problem.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/