Subject: Re: [Sigtran] M3UA:ASPAC Procedures

From: [email-masked]
Date: Tue, 16 Dec 2003 09:34:41 +0530

Brian

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 12/15/2003
06:03:33 PM

Please respond to [email-masked]

Sent by:    [email-masked]

To:    Anjali Gurmukhani/HSS@HSS
cc:    [email-masked]

Subject:    Re: [Sigtran] M3UA:ASPAC Procedures

Agurmukhani,

SE and DE are incompatible.

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

Why are you sending ASPAC before
receiving ASPUP?

>>>>>In DE is it that after sending UP and receiving ack an IPSP should
not send Active till it gets an UP from other side also ?
There is no such mention in current  IG04.

It appears as though one side is SE and the
other DE.  Don't do that.

--brian

[email-masked] wrote:
(Mon, 15 Dec 2003 12:21:26)
>
>
>
>
> Hi
>
> Consider the following  IPSP-IPSP  scenario
>
>          +------------+                 +-------------+
>          |   IPSP1    |                 | IPSP2       |
>          +------------+                 +-------------+
>
>                         ASPUP
>                     -------------->
>
>                               ASPUP-ack
>                     <--------------------
>
>                        ASPAC
>                  | ------------------------>
>                  |
>              T(retrans)
>                  |            ASPUP
>                  | <-------------------------
>                  |
>                  |   ASPUP-ack
>         state->Inact------------------------->
>                  |
>                 expiry
>                ------          ASPAC
>                     -------------------------->
>
>                                    ASPAC-ack
>                   <----------------------- state->Active
>         discarded
>         since state Inact
>
>
> In the above scenario, IPSP1 does not stop timer T(ack)
> after receiving ASPUP message as a result of which  ,
> Active messages are  retransmited. The Active message
> from IPSP1 changes the state of Remote AS
> at IPSP2 to active  and IPSP2 sends back an ack.
> But  IPSP1  discards  Aspac-ack received from IPSP2 .
> As a result of above there is a state mismatch at two sides.
>
> Currently RFC mentions the behaviour when UP message
> is received in Active state but not when Active message has
> been sent and ack is awaited.
>
> What should be the correct behaviour in above case
> when expected is Active-ack and received is ASPUP?
>
> One solution is to stop the timer T(ack) on receiving Up
> and hence not retransmit Active messages.
> Also indicate  LM  that the state is Inactive due to received
> UP message so that Active is initiated from LM  again.
>
> Please comment
>
> Regards
> Anjali
> www.hssworld.com
> Hughes Software Systems
>
>
>
>
>
>
>
>
>
>
>
>
> "DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited
> (HSS) and is intended solely for the use of the individual to whom it is
> addressed. It may contain  privileged or confidential information and
> should not be circulated or used for any purpose other than for what it
is
> intended. If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying, altering,
or
> disclosing the contents of this message. HSS accepts no responsibility
for
> loss or damage arising from the use of the information transmitted by
this
> email including damage from virus."
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

--
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 01:10:06 -0700

Agurmukhani,

Please see comments below...

[email-masked] wrote:                                                 (Tue, 16 Dec 2003 09:34:41)
>    Please have a look at the following

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.

--brian

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