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

From: "TOLGA ASVEREN" <[email-masked]>
Date: Wed, 26 Feb 2003 16:03:15 +0200

Brian,

Samuel,

Samuel Dur D. Jeyaseelan wrote:
(Wed, 26 Feb 2003 06:06:29)
>
> Brian,
> I understood the same.But there may be a time where SG can request k ASP
> to become active in order to handle the heavy traffic.
> Because configured 'n' ASPs are sufficient to handle the normal traffic
> but when traffic increases than 'normal traffic' from SS7 network towards
> SG- this case SG may request k ASP to become active.

The SG has no understanding of the traffic handling capability of the ASPs.

The only thing it has in the number "n".
[TOLGA]If SG knows only about "n" (and nothing else) how can it decide to
direct traffic or not? In such a case, isn't the only option for SG to wait
for n ASPs to be ACTIVE? Otherwise, which other paramaters are playing a
role for that decision?

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Feb 2003 07:26:47 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Wed, 26 Feb 2003 16:03:15)
> for n ASPs to be ACTIVE? Otherwise, which other paramaters are playing a

The other option is for the SG not to wait.

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 26 Feb 2003 07:38:38 -0700

TOLGA,

Please note that the option in the RFC states that the "SGP" MAY wait,
not that the "SG" MAY wait.  The SG might have the AS active for more
than n ASPs with other SGPs, or more than n ASPs combined across the
SGPs.

Even if there wasn't SS7 considerations, saying that an SGP "SHOULD"
wait would be foolish, particularly if all the APSs are merrily
handling AS traffic via other SGPs in the same SG.

Saying the "SG" "SHOULD" wait would place an undue requirement on the
SGP to make its decision based upon their peer SGP's (possibly incorrect
or untimely) view all ASPs state for the AS.

--brian