Subject: Re: [Sigtran] Re: M3UA Notify message

From: "TOLGA ASVEREN" <[email-masked]>
Date: Tue, 25 Feb 2003 13:32:04 +0200

Samuel,

Why not let SG decide, what to do and leave it flexible in the
specification? SG will inform ASPs about its decision with NTFYs anyhow.

      Tolga

Brian,

  Alcatel USA, Inc.                  Internet: <userid>@ssd.usa.alcatel.com
  1000 Coit Road, Plano, Texas 75075
  ******* The opinions expressed are not those of Alcatel USA, Inc. *******

On Tue, 25 Feb 2003, Brian F. G. Bidulock wrote:

> TOLGA,
> TOLGA ASVEREN wrote:
(Tue, 25 Feb 2003 08:39:11)
> >
> > Not necessarily because I disagree with some change, but just to
clarify
> > where the changes might take us:
>
> If we cannot agree, we let the RFC stand.
>
> > NTFY was used till now only as an advisory message, this will be
changed.
>
> No it will not.  An ASP is not forbidden from acting on any Notify
message.
> All Notify messages are still advisory.  The ASP can take into
consideration
> Notify messages, information that it has about other ASPs, the time of
day,
> direction of the wind, etc.
>
> > Starting/stopping(till now we focused more on starting but why not
stopping
> > also? So SG can decide based on load/other dynamic conditions when to
stop
> > traffic to/from AS) traffic will be controlled by SGP with NTFY.
>
> The SG has always been permitted to start or stop traffic when it
considers
> it necessary and has always been permitted to perform its necessary
functions
> with the SS7 network.  The SGP can send ASPIA Ack or drop associations
any
> time it wishes to stop traffic.

Please let me know what are we achieving by stopping the traffic in the
following case(n+k - reduntancy)

When 'n' ASPs are active
------------------------
SLS-X  ---->ASP1
SLS-Y  ---->ASP2

When ASP1 goes down
-------------------
SLS-(Y,X)  ----->ASP2

Here 3 cases can be dealt

case 1) If SG receives  message with SLS Y - this traffic can be
        successfully (100%) handled by ASP2 according to the configured
        databse.

case 2) If SG receives messages with SLS X and Y - this traffic can be
        successfully (100%) handled by ASP2, provided congestion has not
        occured(according to q.704 section 3.8.2)

case 3) Don't allow SG to process the traffic when n<2 ?????????.
        SG disallows traffic when n=0.

IMO, SG has capability to reroute the traffic to ASP1 and there is no
meaning if SG stops traffic when n < 2.

This is just like a MTP3 link failure concept when link1 goes down ,
traffic carried by link1 will be rerouted to available link.
All we need to do at SG is just change the SLS-ASP dynamic table to carry
SLS X.

--Samuel
>
> > IMO, this requires still a change to the original AS state machine for
> > transitions from INACTIVE to ACTIVE and possibly from ACTIVE to
PENDING.
>
> It does not.  The SG is only withholding a Notify message as proscribed
> by the RFC.
>
> > In general all this will change the meaning of ASPAC/ASPAC-ACK
exchange, it
> > will mean that ASP is ready to be triggered to send/receive traffic for
a
> > specific AS (something to be determined just by ASP, when the
triggering
> > will happen will be decided by SGP)rather than ASP can start to
> > send/receive traffic for a specific AS(something to be determined by
both
> > ASP and SGP). I believe this migth require some other changes
throughout
> > the document. For example instead of unsolicited ASPIA-ACK, I would
think
> > SGP should send NTFY(INACTIVE). My opinion is, if we are changing
> > something, let's do it clean and correct.
>
> No nothing changes here because withholding NTFY(ACTIVE) is already part
> of the RFC.  Nothing in the RFC changes.
>
> >
> > IMO, overall this is more than just a clarification, let's decide
carefully
> > to prevent rollbacks (as much as possible).
>
> Not even clarification is required.  The RFC details the necessary
actions.
>
> The only thing that needs to be done is strike section 3.15 from the IG
> because it conflicts with the RFC (which is fine as it is).
>
> --brian
>
> --
> 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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 25 Feb 2003 04:48:08 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Tue, 25 Feb 2003 13:32:04)
> specification? SG will inform ASPs about its decision with NTFYs anyhow.

That's what it already says in the RFC.  Strike IG 3.15.

--brian

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Tue, 25 Feb 2003 06:08:39 -0600 (CST)

Tolga,

From this thread we can end up with two kinds of SGs.

The SG which decides to stop taking the traffic when 'n' changed
from '2' to '1'.

The other SG which decides to continue the traffic  when 'n' 
changed from '2' to '1'.

When performance is considered, i think everyone will prefer second case.
Second case follows the existing network standards.But first case does
not follow any standards.

If at all change is required following things to be made clear.

  According to RFC 'k' ASP is NOTIFIED only when #ASPs < n - means
  existing ASP1 has been failed so SG sends NTFY to 'k' ASP in order to 
  maintain the traffic stability. - This is what RFC says but when traffic
  increases and SG is unable to handle the traffic with 'n=2' ASPs , now
  SG can request 'k' ASP to become active- this is new case to be decided.

--Samuel