Subject: [Sigtran] M3UA Notify message

From: ksrinivas <[email-masked]>
Date: Wed, 12 Feb 2003 13:42:16 +0530

Brian,

     Can you tell me when an SGP should send Notify(AS-PENDING) and
Notify(Insufficient ASP Resources Active in AS)?. I felt RFC and IG of
M3UA is not clear on these two.

--Srini

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 02:40:02 -0700

Srini,

ksrinivas wrote:                                                                 (Wed, 12 Feb 2003 13:42:16)
> M3UA is not clear on these two.

It think that it is pretty straight-forward.

NTFY(Insufficient ASPs) is sent for an AS by an SGP when the number of
ASPs in the ASP-ACTIVE state for the AS falls below "n", but not to
zero, (as a result of ASP failures or deactivations); where "n" is the
minimum number of active ASPs defined for the AS.  So this notification
is only sent if "n" is greater than 1.

NTFY(AS-PENDING) is sent for an AS by an SGP when the number of ASPs in
the ASP-ACTIVE state for the AS falls to zero (as a result of ASP
failures or deactivations).

Although there is the notification to indicate when there is insufficent
ASPs available for an AS, there is no notification that there are
sufficient ASPs for an AS.  This causes problems for ASP wishing to use
the first notification as in indication to go active.  There should be a
NTFY("Sufficient ASPs active") to notify that the opposite of
insufficient ASPs active is now true.

I also send these two notifications to any ASP that transitions from the
ASP-DOWN state to the ASP-INACTIVE state for the AS when the numer of
ASPs is below "n" or is zero and the T(pend) timer has not yet expired.
I also send other state notifications for the AS in this case as well
(i.e, NTFY(AS-ACTIVE), NTFY(AS-INACTIVE)).

As there is no procedure for a newly inactive ASP to audit the state of
the AS, this helps ASPs which are just coming up for an AS to
immediately determine the state of the AS and their next best course of
action for the AS.

In addition to notifications resulting from AS state changes, I think we
should say in the IG:

   The SGP SHOULD send a NTFY message indicating the state of the AS to
   all ASPs newly becoming ASP-INACTIVE from ASP-DOWN for each AS.

--brian

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

---

From: ksrinivas <[email-masked]>
Date: Wed, 12 Feb 2003 16:10:48 +0530

Brian,

> failures or deactivations).

I understood the same way initially. But the section 3.15.2 of M3UA IG-02 has confused me. The following is the
text from this section.

"AC2PN: one ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP-DOWN states, causing the number of ASPs in
ASP-ACTIVE drop below n."

So the AS moves to AS-PENDING state when ASPs in ASP-ACTIVE drop below 'n' (but not necessarily zero). Do we not
have to send Notify(AS-PENDING) when AS has moved to AS-PENDING state?.

--Srini

---

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

ksrinivas,

ksrinivas wrote:                                                                 (Wed, 12 Feb 2003 16:10:48)
> I understood the same way initially. But the section 3.15.2 of M3UA IG-02
> has confused me. The following is the text from this section.
> 
> "AC2PN: one ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP-DOWN
> states, causing the number of ASPs in ASP-ACTIVE drop below n."
> 
> So the AS moves to AS-PENDING state when ASPs in ASP-ACTIVE drop below 'n'
> (but not necessarily zero). Do we not have to send Notify(AS-PENDING) when
> AS has moved to AS-PENDING state?.

I see.

I largely disagree with the IG section 3.15.2.  Consider that the new
description of the AS-PENDING state is:

    AS-PENDING: An active ASP has transitioned from ASP-ACTIVE to ASP-
    INACTIVE or ASP-DOWN and it was the number n active ASP in the AS.  A
    recovery timer T(r) SHOULD be started and all incoming signalling messages
    SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r)
    expires, the AS is moved to the AS-ACTIVE state and all the queued
    messages will be sent to the ASP.

I think that it would be undesireable for an SGP to queue "incoming"
signalling messages when the number of active ASPs is less than "n" for a
number of reasons stated on the "n+k redundancy" thread.

For example, at quiet periods, when there is not much traffic, is there any
reason to stop service because one ASP happens to be inactive?  (Remember that
this only counts for load-sharing and broadcast modes.)

I believe that the number of active ASPs less than "n" corresponds to the
AS-ACTIVE state (as in the RFC).

I disagree with the modified state machine as arranged between Tolga and
Javier with little input from others.

As far as I'm concerned the AC2PN transition is caused by the last active ASP
moving to the ASP-INACTIVE or ASP-DOWN state or only if the SGP follows the
"MAY" (and withholds traffic for m < n).

--brian

---

From: ksrinivas <[email-masked]>
Date: Wed, 12 Feb 2003 18:29:23 +0530

Brian,

>>I believe that the number of active ASPs less than "n" corresponds to the AS-ACTIVE state (as in >>the RFC).

I agree with this.

--Srini

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 12 Feb 2003 05:08:14 -0800 (PST)

Brian,
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> ksrinivas wrote:                                    
>                             (Wed, 12 Feb 2003
> 16:10:48)
> > > ksrinivas wrote:                                
>                                 (Wed, 12 Feb 2003
> 13:42:16)
[TOLGA] If this is the desired behavior then the
redundancy model to be choosen is 1+n . IMO, n+k
redundancy means that n active ASPs are required and I
think there is a difference between required and
preferred. IMO NTFY(Insuff. ASP resources) is used for
the case where more active ASPs are preferred. So, for
n+k redundancy case, when number of active ASPs fall
below n, AS state changes but not for 1+k case.
> Javier with little input from others.
[TOLGA]For n=1, the new n+k state machine is exactly
the same like the old one. But it just makes the state
transitions clear for the case where n>1 is
required.(everything related with this change was
discussed on the list, just I think you were busy at
that time ;) )
> "MAY" (and withholds traffic for m < n).
[TOLGA]I think, that "MAY" is a potential source for
problems, when ASP and SGP interprete it differently.
By letting the state of AS change for n+k case when
number of active ASPs fall below n, the goal was to
get rid of this ambiguity (but of course for the
"preferred" case, it is still there)
> --brian

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 12 Feb 2003 05:15:58 -0800 (PST)

If the traffic mode is 1+k I agree with that
statement but if it is n+k, I disagree.

   Tolga
--- ksrinivas <[email-masked]>
wrote:
> Brian,
> 
> >>I believe that the number of active ASPs less than
> "n" corresponds to the AS-ACTIVE state (as in >>the
> RFC).
> 
> I agree with this.
> 
> --Srini
>

---

From: ksrinivas <[email-masked]>
Date: Wed, 12 Feb 2003 18:54:13 +0530

Tolga,

   Can you please tell me when to send Notify(AS-PENDING) and
Notify(Insufficient ASP Resources Active in AS)?.

--Srini

Tolga Asveren wrote:

> > "n" corresponds to the

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 12 Feb 2003 05:32:41 -0800 (PST)

Srini,

IMO Notify(AS Pending) is sent when AS chnages to
AS-Pending state. Notify(Insuff. ASP resources) is
sent, when there is no AS state change but SGP wants
to inform INACTIVE ASPs that it wants them to switch
to ACTIVE state. I think, the difference is required
v.s. preferred. For example if I am sure that I will
need 2 ACTIVE ASPs then I would use n=2. But if I
think that mostly 1 is enough but according to traffic
load I might need a second one I would use n=1 and use
NTFY(Insuff. ASP resources Active) when necessary. In
fact for that scenario, the number of preferred ASPs
is not predefined, i.e. it changes with traffic load,
so I wouldn't think it can be prearrenged between SGP
and ASP. But if one is sure about the required number
of ASPs then this value can be configured both on ASP
and SGP and an AS state chnage based on that value
seems appropriate to me.

    Tolga
wrote:
> > > "n" corresponds to the AS-ACTIVE state (as in
> >>the
> > > RFC).
> > >
> > > I agree with this.
> > >
> > > --Srini
> > >
> > >                                   (Wed, 12 Feb
> 2003
> > > > > > >      Can you tell me when an SGP should
> send
> > > Notify(AS-PENDING) and
> > > > > > > Notify(Insufficient ASP Resources Active
> in
> > > AS)?. I felt RFC and IG of
> > > > > > NTFY(Insufficient ASPs) is sent for an AS
> by
> > > an SGP when the number of
> > > > > > ASPs in the ASP-ACTIVE state for the AS
> falls
> > > below "n", but not to
> > > > > > minimum number of active ASPs defined for
> the
> > > AS.  So this notification
> > > > > > NTFY(AS-PENDING) is sent for an AS by an
> SGP
> > > when the number of ASPs in
> > > > > > the ASP-ACTIVE state for the AS falls to
> zero
> > > (as a result of ASP
> > > > > has confused me. The following is the text
> from
> > > this section.
> > > > >
> > > > > states, causing the number of ASPs in
> ASP-ACTIVE
> > > drop below n."
> > > > >
> > > > > So the AS moves to AS-PENDING state when
> ASPs in
> > > ASP-ACTIVE drop below 'n'
> > > > > (but not necessarily zero). Do we not have
> to
> > > send Notify(AS-PENDING) when
> > > >     INACTIVE or ASP-DOWN and it was the number
> n
> > > active ASP in the AS.  A
> > > >     recovery timer T(r) SHOULD be started and
> all
> > > incoming signalling messages
> > > >     SHOULD be queued by the SGP. If an ASP
> becomes
> > > ASP-ACTIVE before T(r)
> > > > I think that it would be undesireable for an
> SGP
> > > to queue "incoming"
> > > > signalling messages when the number of active
> ASPs
> > > is less than "n" for a
> > > > number of reasons stated on the "n+k
> redundancy"
> > > thread.
> > > >
> > > > For example, at quiet periods, when there is
> not
> > > much traffic, is there any
> > > > reason to stop service because one ASP happens
> to
> > > be inactive?  (Remember that
> > > > this only counts for load-sharing and
> broadcast
> > > modes.)
> > > >
> > > > As far as I'm concerned the AC2PN transition
> is
> > > caused by the last active ASP
> > > > moving to the ASP-INACTIVE or ASP-DOWN state
> or
> > > only if the SGP follows the

---

From: ksrinivas <[email-masked]>
Date: Wed, 12 Feb 2003 19:42:57 +0530

Tolga,

>>Notify(AS Pending) is sent when AS changes to AS-Pending state.

So as per section 3.15.2 of M3UA IG, AC2PN causes AS state change to
AS-PENDING and forces to send Notify(AS Pending). i.e., when ASPs in the
ASP-ACTIVE state for the AS falls below "n".

>>For example if I am sure that I will need 2 ACTIVE ASPs then I would
use n=2. But if I think that mostly 1 is enough but according to traffic
load I might need a second one I would use n=1 and use NTFY(Insuff. ASP
resources Active) when necessary.

Do you mean to say that NTFY(Insuff. ASP resources Active) would be used
to make more than 'n' ASPs ACTIVE when necessary.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 08:40:14 -0700

Tolga,

I disagree strongly.  When we build n+1 redundant systems for carrier
grade operation we do not stop service when a processor is still able
to provide service.

If I have 3 processors in a 2+1 arrangement (where 2 are needed to handle
the maximum engineered load and 1 is spare), I do not stop service just
because I have only 1 processor alive.  It just means that the system
will not be able to handle the maximum engineered load with 1 processor.

Overload is a different issue.  If the 1 remaining processor is overloaded,
it should use overload controls to keep itself alive.  In M3UA's case this
could be overload controls at ISUP level or nodal TFC at MTP level or even
SCTP flow control (failing to service read buffer).

Having the SG move to the AS-PENDING state when the number of active ASPs
fall below "n" (2 in the case above) is completely undesirable.

I thought I made this clear on the "n+k redudancy" thread.

I strongly disagree with the changes of section 3.15 of the IG.

--brian

Tolga Asveren wrote:                                                                 (Wed, 12 Feb 2003 05:15:58)

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 12 Feb 2003 11:55:30 -0800 (PST)

Brian,
> will not be able to handle the maximum engineered
[TOLGA]If in that configuration it is not mandatory to
stop traffic when 1 processor is alive, then IMO the
appropaite traffic mode should be 1+n.
> I strongly disagree with the changes of section 3.15
[TOLGA] When n=1 for the satet machine in IG, it will
be the same like the state machine in IG. So, will it
still cause a serious problem? (but let's discuss and
finalize this issue)

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 12 Feb 2003 11:57:30 -0800 (PST)

Srini,
> ASP-ACTIVE state for the AS falls below "n".
[TOLGA] That is my understanding. And of course n can
be 1.
> to make more than 'n' ASPs ACTIVE when necessary.
[TOLGA]That is my understanding.
> > > > > >>I believe that the number of active ASPs
> less
> > > than
> > > > >                                   (Wed, 12
> Feb
> > > > > > > I understood the same way initially. But
> the
> > > > > section 3.15.2 of M3UA IG-02
> > > > > > > "AC2PN: one ASP in ASP-ACTIVE state
> moves to
> > > > > ASP-INACTIVE or ASP-DOWN
> > > > > > I largely disagree with the IG section
> 3.15.2.
> > > > > Consider that the new
> > > > > >     AS-PENDING: An active ASP has
> transitioned
> > > > > from ASP-ACTIVE to ASP-
=== message truncated ===

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 13:10:33 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 12 Feb 2003 11:55:30)
> appropaite traffic mode should be 1+n.

It is NEVER the case that it is mandatory to stop traffic
when the number of active processors falls below anyting
but 1.

You are interpreting the n in n+k to mean "the number of
preocessors beneath which the system will stop working."

This is not what n in n+k is used for in telephony.  The
n is "the number of precessors beneath which the system
will not be able to process the engineered maximum load."

You simply have the wrong concept of n.

> still cause a serious problem? (but let's discuss and

You have the wrong n.

AS-PENDING state should only be entered when the all the
ASPs are inactive.

Insuffient ASPs active should be sent when the number of
active processors falls below n (n is the number of
processors required to process the engineered maximum load).

If the ASPs want to follow your non-telephony concept of n,
they are welcome to deactivate when they receive the
Insuffient ASPs notification.

Strike section 3.15. from the IG and leave things the way
they are in the RFC.  That will resolve the issue.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 12 Feb 2003 12:38:47 -0800 (PST)

Brian,
wrote:
> 11:55:30)
> > > I disagree strongly.  When we build n+1
> redundant
> > > systems for carrier
> > > If I have 3 processors in a 2+1 arrangement
> (where 2
> > > are needed to handle
> > > the maximum engineered load and 1 is spare), I
> do
> > > not stop service just
> > > will not be able to handle the maximum
> engineered
> > > load with 1 processor.
[TOLGA]If the consensus is that there is no need for
the concept of n+k traffic mode, where n is mandatory,
I would consider this also as a solution (in fact this
was one of the proposals made)But this also requires
some changes to be done to RFC (please see below)
> 
> > > 
> > > Overload is a different issue.  If the 1
> remaining
> > > processor is overloaded,
> > > could be overload controls at ISUP level or
> nodal
> > > TFC at MTP level or even
> > > Having the SG move to the AS-PENDING state when
> the
> > > number of active ASPs
> > > fall below "n" (2 in the case above) is
> completely
> > > undesirable.
> > > 
> > > I thought I made this clear on the "n+k
> redudancy"
> > > thread.
> > > 
> > > I strongly disagree with the changes of section
> 3.15
> > > of the IG.
[TOLGA]I disagree with your statement that leaving RFC
as it is provides a solution.
4.3.4.3 ASP Active Procedures*6th paragraph before the
end)
"For the n+k redundancy case, ASPs which are in that
AS should coordinate among themselves the number of
active ASPs in the AS, and should start sending
traffic only after n ASPs are active."

Again in 4.3.4.3 just one paragraphs before
"An SGP or IPSP, upon recepition of an ASP Active
message for the first ASP in a Loadshare AS, MAY
choose not to direct traffic to a newly active ASP
until it determines that there are sufficient
resources to handle the expected load(e.g., until
there are "n" ASPs in state ASP-ACTIVE in the AS). In
this case, the SGP or IPSP SHOULD withold the
Notify(AS-ACTIVE) until there are sufficient
resources."

Now IMO the first paragraph assumes that depending on
n AS state changes whereas the second one doesn't so
there is a constradiction between them. If we use n
with the meaning you suggest, then I wouldn't think it
should have a role to decide when to start/stop
traffic. In that case, does it have any impact on the
procedures between ASP/SGP? Like that, the only
necessary thing to be indicated in the RFC/IG IMO is
to say, when SGP wants more ACTIVE ASPs for whatever
reason, it should send NTFY(Insuff. ASP resources
Active) and there is no need to mention anything about
n.(and I would think the first paragraph above should
be deleted and the second one modified to make this
work properly -all this assuming there is no ralistic
scenario where n>1 is mandatory-)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 14:17:14 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 12 Feb 2003 12:38:47)
> Notify(AS-ACTIVE) until there are sufficient

There is no problem with the above statement.  Because
the newly active AS was previously inactive, the
inaccessibiliy of the MTP-SAP has already been indicated
to the SS7 network.  There is no traffic to offer until
the SG says otherwise.  It is the SG's responsibility to
determine MTP-SAP (SPMC) state as appropriate, and one
of the things it may consider is the number of ASPs
active within a time window for a newly active AS.

For example, one could set a timer when the first ASP
comes active and if n is surpassed before the timer
expires, indicate availability of the MTP-SAP to the
SS7 network, or if the timer expires, indicate availability
of the MTP-SAP to the SS7 network anyway.

The section above was meant to address the situation where
ASPs activate in a staggered fashion due to reboot and under
traffic backpressure it would behoove the SG to wait for
a short period to let as many come active as are going to
come active (or as many as can handle the engineered max
load, in this case "n") before indicating accessibility of
the AS to the SS7 network.

The first section goes hand in hand with the second.  If
the SG is going to hesitate before indicating that the
MTP-SAP is active, then the ASPs should as well (otherwise
the SG will be forced to send messages on behalf of the
MTP-SAP and can no longer resonably report it inaccessible).

The other statement in the RFC (that the ASPs wait for
NTFY(AS Active) and the SGP witholds NTFY(AS Active) until
"n" ASPs are active) goes hand in hand with these two.

If the SG cares to delay indicating that the MTP-SAP is
accessible to the SS7 network, it should also delay the
sending of NTFY(AS Active).  The ASPs can then know to
suppress sending of messages until receiving NTFY(AS
Active) from the SG and will know when the SG feels
that the MTP-SAP should be declared acessible to the SS7
network.

> traffic.

The decision to start traffic and the decision to stop
traffic are two separate decisions.

In deciding when to start traffic after a failure, it
would be smart to consider the ability of the system to
handle the upcoming load.  This is because ocillations
due to overload has a more disasterous effect on
telephone calls than outage (resource in otherwise
unaffected nodes are consumed to no purpose).  Also,
after an outage occurs there is invariably steep
increase in the traffic that will be initially offered
due to reattempts, particularly where the AS represents
an entire point code.  I have seen outages where the
reattempt pressure was five to ten times the traffic
levels offered just before the failure.

In deciding when to stop traffic the only reasonable
criteria for a telephony system is to only stop traffic
when it is impossible to process any traffic (i.e,
when the number of active ASPs for the AS falls to zero).
Anything else would fail system reliability engineering
considerations and would be excessively costly to the
operator in terms of cash flow.

It appears that it is not a contradiction at all.  The
SG can just not be required to apply the start traffic
criteria to the stop traffic decision, or visa versa.

> In that case, does it have any impact on the

The paragraphs are fine and the meaning of "n" is consistent
across both the start decision and the stop decision.  "n"
represents the number of active ASPs necessary to handle
the maximum engineered load.  In the start decision case,
it is best to wait for "n" ASPs to become available before
flooding them with the reattempt backpressure.  In the
stop decision case, it is best to wait for the AS to go
inactive before pending on the AS.

Again, IMO the RFC is ok as it stands.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 12 Feb 2003 14:09:25 -0800 (PST)

Brian,
wrote:
> Tolga,
> 
> Tolga Asveren wrote:                                
>                                 (Wed, 12 Feb 2003
> 12:38:47)
> > > 
> > > Strike section 3.15. from the IG and leave
> things
> > > the way
[TOLGA]Is there a place in RFC/IG, which indicates
that ASPs SHOULD wait for NTFY(AS Active) to start
send/receive traffic? To my knowledge there isn't and
this depends just on receiving ASPAC-ACK and on the
number of ACTIVE ASPs -based on the above paragraph-
IMO the not nice thing with those two statements is
that ASPs SHOULD wait for n ACTIVE ASPs to start
sending traffic, whereas SGP MAY withhold traffic.
There should be a consistency between them.
> Again, IMO the RFC is ok as it stands.
[TOLGA]If you think that for start case it is best to
wait for n, then SG SHOULD withhold traffic instead of
MAY withhold traffic(like ASP SHOULD wait for n ACTIVE
ASPs) In fact as far as I recall the request to change
this MAY to SHOULD was the reason, why the debate
about n+k started. IMO how ASP and SGP behave
regarding n should be the same.
If this MAY is changed to SHOULD, I would think still
an update is necessary to AS state machine for
AS-INACTIVE to AS-ACTIVE transition (nth ASP goes
ACTIVE instead of 1st ASP goes ACTIVE and we don't
touch transition from ACTIVE to PENDING)
If nobody thinks that there is a realistic scenario,
where n>1 is mandatory, i.e. less than n ACTIVE ASP
will change AS state to PENDING-, then I think the
approach you explained makes sense.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Feb 2003 20:00:02 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Wed, 12 Feb 2003 14:09:25)

> There should be a consistency between them.

Also, section 4.3.4.3 middle of page 82, top of page 83 (just after
the sections you quoted):

Loadshare:

   An SGP or IPSP, upon reception of an ASP Active message for the first
   ASP in a Loadshare AS, MAY choose not to direct traffic to a newly
   active ASP until it determines that there are sufficient resources to
   handle the expected load (e.g., until there are "n" ASPs in state
   ASP-ACTIVE in the AS).  In this case, the SGP or IPSP SHOULD withhold
   the Notify (AS-ACTIVE) until there are sufficient resources.

Broadcast:

   An SGP or IPSP, upon reception of an ASP Active message for the first
   ASP in a Broadcast AS, MAY choose not to direct traffic to a newly
   active ASP until it determines that there are sufficient resources to
   handle the expected load (e.g., until there are "n" ASPs in state
   ASP-ACTIVE in the AS).  In this case, the SGP or IPSP SHOULD withhold
   the Notify (AS-ACTIVE) until there are sufficient resources.

As the SGP SHOULD withhold the Notify (AS-ACTIVE), the ASP can rely on
its being withheld as an indication that the SGP is not directing traffic
to to the active ASPs for the AS because insufficient ASPs have been
activated.  Because the ASP SHOULD withhold traffic in the case of
insufficient ASPs, the ASP SHOULD NOT start traffic until it receives
Notify (AS-ACTIVE) from the SGP.  That seems pretty straightforward to me.

Also, see example 5.1.4.

> regarding n should be the same.

I disagree with SHOULD.  Directing traffic on activation requires
and exchange between the SG and the SS7 network.  These exchanges
are outside the scope of the RFC and the RFC cannot place requirements
on the SS7 network.  Also, in the case of SI granularity AS, the
SG cannot "direct traffic" to the AS.  It will take the expiry of UFC
timers at the remote signalling points before any traffic will be
restarted or directed.  By saying MAY, we are saying that the SG is
graciously permitted to do what it needs to do with respect to the
SS7 network.

However, we do then say that if the SG does not direct traffic that
it SHOULD withold the Notify (AS-ACTIVE) to let the ASP know what it
is doing.  This is SG/ASP interaction and is within the scope of the
RFC.

Also, what the ASPs do with regard to the SG is directly within the
scope of the RFC and the RFC can place the SHOULD requirement on the
ASPs.  The ASPs should not restart traffic until it knows that n ASPs
are up.  And how does it tell this?  Well the RFC alludes to some
inter-ASP coordination which is also outside thes scope of the RFC
(APS to ASP protocol).  The only requirement in the RFC that allows
the ASP to determine that n ASPs are active is that the SG has sent
Notify (AS-ACTIVE) for the AS.

If you want to clarify "SHOULD wait until n ASPs are active" to
"SHOULD wait for Notify (AS-ACTIVE)", feel free, as it seems very
apparent to me anyway (and was the result of the thread just after
last call on the subject, too).

> If this MAY is changed to SHOULD,

MAY cannot change to SHOULD because it is an action towards the
SS7 network upon which M3UA cannot place requirements.

> I would think still

No, the state transition is still valid, it is just that the SGP
SHOULD withhold the Notify (AS-ACTIVE) until the nth ASP is active
iff it withholds traffic.

The current state machine in the RFC is fine.

> approach you explained makes sense.

Putting perfectly good processors out of service by blocking all
traffic to them and creating a complete service outage where one is
not necessary could not possibly be construed as realistic by any
operator.  I'd hate to be in front of Congress explaning that one!

--brian

---

From: ksrinivas <[email-masked]>
Date: Thu, 13 Feb 2003 09:15:41 +0530

Tolga,

    Moreover the SG has to buffer the traffic in such a situation(when load is more).

--Srini

---

From: ksrinivas <[email-masked]>
Date: Thu, 13 Feb 2003 09:56:34 +0530

Tolga,

IMO, in n+k redundancy model, 'n' are needed to handle the maximum
engineered load and the remaining 'k' are to be used as spare. When any
of the Active ASP of 'n' is down/inactive, ASPs of the remaining 'k'
(spare) should be notified for insufficient ASP resources inorder to
move them to ASP Active state to again make 'n' ASP Active to handle the
maximum engineered load.

--Srini

---

From: ksrinivas <[email-masked]>
Date: Thu, 13 Feb 2003 13:01:37 +0530

Brian,

    I agree with your comments. An AS is moved from AS-PENDING to AS-ACTIVE on the first ASP becoming Active. Am I
right?. In that case, Should we send all the bufferred or queued traffic at SG to the first ASP that becomes Active
immediately or wait until n number of ASPs become Active?.

--Srini

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 13 Feb 2003 04:26:23 -0800 (PST)

Brian,
wrote:
> 14:09:25)
[..snip..]
> Notify (AS-ACTIVE) from the SGP.  That seems pretty
[TOLGA]This is not straightforward at all to me. NTFY
is used only as an advisory message. Probably you also
recall that I proposed to use NTFY(AS-ACTIVE) like you
want to use above (just before the text was frozen)
but we end up with the sentence saying that ASP SHOULD
coordinate among themselves number of ACTIVE ASPs and
SHOULD start sending traffic based on that.
> graciously permitted to do what it needs to do with
[TOLGA]IMO, Unless necessary changes are done to make
ASP start traffic based on NTFY, if MAY is not changed
to SHOULD, there is the possibility of inconsistent
behavior between ASP and SGP. Let's say n is 3 and SG
decides to send traffic with the first ACTIVE ASP,
ASPs won't send traffic based on the current M3UA RFC.
If we decide to use NTFY to make ASPs aware when to
start traffic, then still I would think concept of n+k
is not necessary on procedures between ASp/SGP. SGP
decides when traffic will start and will inform ASPs
about that.
> Notify (AS-ACTIVE) for the AS.
[TOLGA]Nowhere it is stated that NTFY is to be
interpreted so stronglt by ASP and till now we always
interpreted NTFY only as an advisory message.
> last call on the subject, too).
[TOLGA]This is quite a change logically (but not
necessarily I disagree, what do the others think?). 
> iff it withholds traffic.
[TOLGA] Something not clear to me, let's assume SG
wants to withhold traffic till 3 ASPs are ACTIVE. Will
it advertise PC of AS available to SS7 network with
the first ACTIVE ASP? 
It is strange to me thinking that AS state changes to
ACTIVE and NTFY(AS ACTIVE) is withhold. I would think,
AS chnages to ACTIVE and NTFY is sent. But when AS
changes to ACTIVE state can be decided by SG itself.
> operator.  I'd hate to be in front of Congress
[TOLGA]I was thinking on the cases, where one is sure
that with less than n ACTIVE ASP, congestion will
happen soon, so just to act a bit in advance.

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 13 Feb 2003 04:29:10 -0800 (PST)

Srini,
> such a situation(when load is more).
[TOLGA] I don' think so, because if n is interpreted
as mandatory, AS won't be advetised as available to
SS7 netwrok till n ASPs are ACTIVE, so there won't be
any load at all.
> the number of active ASPs
> 3.15 of the IG.
> 05:15:58)

---

From: ksrinivas <[email-masked]>
Date: Thu, 13 Feb 2003 18:20:13 +0530

Tolga,

   The situation which I meant is "When an ASP in the AS goes Inactive
by making number of Active ASPs less than 'n' and also at the same
movement traffic is more". In this situation if the traffic is stopped
sending to the AS and tried buffering, I think we will run
out-of-buffers in no time.

--Srini

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 13 Feb 2003 05:11:12 -0800 (PST)

Srini,
> out-of-buffers in no time.
[TOLGA]I understand your concern but is the situation
different if you have one big ASP, which can handle a
lot of traffic? When it goes INACTIVE switching AS to
pending state, still one might run out of buffers, if
no new ASP is ACTIVE soon. For n mandatory (not
because I think we should go in that direction) case,
IMO it is similar, there are n-1 ACTIVE ASPs, and if
no new ASP becomes ACTIVE soon, one migth run out of
buffers.
> (where
> > > 2 are needed to handle
> > > > because I have only 1 processor alive.  It
> just
> > > means that the system

---

From: ksrinivas <[email-masked]>
Date: Thu, 13 Feb 2003 19:27:02 +0530

Tolga,

> no new ASP becomes ACTIVE soon, one migth run out of

Atleast for n > 1 case, as Brian suggested, can we not decrease incoming
traffic by initiating the congestion procedures and distribute the
existing traffic over the available Active ASPs?.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Feb 2003 07:44:06 -0700

Srini,

The decision to restart while pending is a different decision again
from the start or stop decision.  If a brief period of time has
elapsed, the network conditions at the time of restart are the same
as the network conditions immediately before the restart.  IMO from
the AS-PENDING state, the SG should move back to AS-ACTIVE with the
first ASP coming active, as in the RFC.

How the SG controls the restart decision is by setting the pending
timer.  It was made clear that the T(pending) timer can be 0.

For M3UA, time-controlled changeover and controlled rerouting buffer
messages for about a second.  T(pending) timer values of 1 or 2 seconds
are very usable, but the operator is welcome to set the timer to 0
and force the start decision immediately.

I think by controlling the timeout value one can get whatever behavior
the operator wants.

The ASP, on the other hand, cannot really know what T(pending) timeout
value is set at the SG and should treat the situation as though it is
initially starting.  That is, it should wait for NTFY(AS-ACTIVE) before
starting traffic.  That way, if the SG is peforming the start deicision
instead of the restart decision, and waiting for n ASPs, it will withhold
NTFY(AS-ACTIVE) until n are up, and things should work correctly.

Sound good?

--brian

ksrinivas wrote:                                                                 (Thu, 13 Feb 2003 13:01:37)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Feb 2003 08:01:11 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 13 Feb 2003 04:26:23)
> SHOULD start sending traffic based on that.

The ASP is not prohibited from using the NTFY messages
to deteremine when to do things.

> ASPs won't send traffic based on the current M3UA RFC.

SHOULDN'T and won't are two different things.

> decides when traffic will start and will inform ASPs

Understand that the SGP does not decide when traffic
will start because it is not generating any traffic.
All the SG can do is inform the SS7 network that the
AS is accessible and in the SI case can't even do that.
You cannot make MAY a SHOULD because the for SI AS
the SG cannot even do anything to "direct traffic".

> interpreted NTFY only as an advisory message.

It is advisory, but because a SHOULD is placed on the SG,
the ASP can reasonably rely on the NTFY being sent when
"n" ASPs are active.

> it advertise PC of AS available to SS7 network with

In the case of SI AS there is nothing to advertise.

> changes to ACTIVE state can be decided by SG itself.

That's just the way we stated it in the RFC.

> happen soon, so just to act a bit in advance.

That is a bad assumption: that congestion will happen soon.

During normal operation a telephony system normally handles less
than 1/10th of its maximum load.  During a large part of the day
telephony platforms handle trivial traffic.  The platforms are
engineered for peak high-day operation (for ISUP platforms, this
is Mother's Day busy hour).  So, perhaps your assumption might
hold at 9:00 am on Mother's Day if the platform is close to
being expanded, but not during the other 8,550 hours of the year,
or if the platform has capacity left in its planning cycle.

Decisions to stop cash flow on revenue affecting platforms are
best left manual.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 13 Feb 2003 14:55:01 -0800 (PST)

Brian,
[..snip...]
> to deteremine when to do things.
[TOLGA]I think it is clear that NTFY as of now has
only advisory meaning. According to RFC/IG ASP will
start traffic based on the paragraph I referred, i.e.
when ASP knows that n ASPs are ACTIVE, not based on
NTFY(AS ACTIVE). 

[..snip..]
> the SG cannot even do anything to "direct traffic".
[TOLGA]If n is not interpreted as mandatory, there is
no need to change MAY to SHOULD, otherwise there is.
When I say starting traffic, I refer to the
communication between ASP and SGP, so I don't believe
there is anything to understand special from my point
of view. Also for SI RKs, there is no problem, SG can
reply with UPU for traffic destined to that AS and can
drop any message destined for that AS, when it is
INACTIVE.
If n is to be interpreted as the engineered value for
high taffic case (which also sounds more realistic to
me), then I see changing the meaning of NTFY as the
only solution, because which value SG is going to
decide as enoguh at a given time can't be known by
ASPs. Basically this will make the concept of n
disappear on ASP side.

[..snip..]
> the ASP can reasonably rely on the NTFY being sent
[TOLGA]But unless this is stated in RFC/IG, we can't
rely that ASPs will work that way.
> 
> > > No, the state transition is still valid, it is
> just
> > > that the SGP
> > > SHOULD withhold the Notify (AS-ACTIVE) until the
> nth
> > > ASP is active
[TOLGA]If I need to be more precise for SI replying
with UPU and for PC advertising availability, still
the real question is, when will SG decide that
SPMC/User Part is available, I would think only then,
when it decides to send NTFY(ACTIVE)?
> That's just the way we stated it in the RFC.
[TOLGA]Now, in fact using NTFY on ASP to decide to
start traffic will introduce a new state to the state
machine(unless transition from INACTIVE to ACTIVE is
modified in the AS state machine with something like
determined by SG based on number of ACTIVE ASPs),
ACTIVE but not allowed to send traffic. What about
stopping traffic? Will SG have the rigth to send
NTFY(INACTIVE) and for ASPs to stop traffic and keep
them still in ACTIVE state?

> That is a bad assumption: that congestion will
[TOLGA]Unless somebody comes up with an
counter-example, I also would think that n>1 as
mandatory is not necessary.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Feb 2003 18:41:01 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 13 Feb 2003 14:55:01)
> drop any message destined for that AS, when it is

There you go saying what the SG will do towards the
SS7 network.  The RFC does not place requirements on what
the SG does towards the SS7 network.  It is in the SG's
discretion to manage the SPMC and MTP-SAP as it sees fit.

> ASPs.

The ASP can always be configured with the same number
as the SG.

The ASP can always know when the SG sends traffic
(because the ASP receives traffic when the SG sends it.)

> Basically this will make the concept of n
> disappear on ASP side.

It does not disappear at all.  The ASPs need to know
how many of them are required to meet n+k redundnacy
requirements, to meet the engineered load, when a
standby should be activated into the pool or an excess
active ASP removed from the pool.  On start the ASPs
need to know how many of them need to activate.

The need to know these things namely because the
SG MAY withhold traffic until "n" of them are up and
they SHOULD not send traffic until "n" of them are up.

> rely that ASPs will work that way.

ASPs don't have to work that way.  You should know this
about M3UA by now: there are a number of ways to peel
the same onion.  The ASP designer can rely on this SHOULD
or not.  Just don't say that there is no way for the
ASP to tell what the SG is doing: it can by what
notifications it receives.  What it decides to do with
those notifications are up to the ASP.

But it still stands that an ASP SHOULD NOT send traffic
until "n" of them are up for the start scenario.

Perhaps if we change the word "send" to "initiate" that
would satisfy you.

As in: ...the ASP SHOULD NOT initiate traffic until it
knows that "n" ASPs are active...

> when it decides to send NTFY(ACTIVE)?

The RFC does not place requirements on how the SG
manages the SPMC/MTP-SAP and it does not specify the NIF.
This is why we say MAY to directing traffic towards
ASPs.  When will the SG do this?  When it's good and
ready.  The requirement is on the SGP/ASP exchange: that,
IF the SG waits to initiate traffic then it also waits
to send NTFY(AS-ACTIVE).

> them still in ACTIVE state?

Your being way to pendantic.  The state diagram is
an overview.  There are about eight states missing,
such as:  ASP Active sent, waiting for ASP Active Ack,
ASP Inactive sent, waiting for ASP Inactive Ack,
ASP Down sent, waiting for ASP Down Ack.

You see the ASP does not send traffic after sending
ASP Inactive, but it can expect to receive traffic
until it receives ASP Inactive Ack, etc, etc,

It is an overview diagram.  If you want to crack out
the SDLs you will have 50 pages before your done.

> mandatory is not necessary.

Good.  Then we strike section 3.15 of the IG, right?

--brian

---

From: ksrinivas <[email-masked]>
Date: Fri, 14 Feb 2003 10:24:50 +0530

Brian,

   1. Is the T(pending) different from T(r)?. (If Yes, RFC / IG does not include this).
   2. Should we start it after An AS is moved from AS-PENDING to AS-ACTIVE i.e., on the first ASP becoming Active?.
   3. On timeout of T(pending) or after n number of ASPs becoming Active, should we send Notify(AS-Active)?.
   4. ASP should wait for NTFY(AS-ACTIVE) before starting traffic.

Is my understanding right?.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Feb 2003 23:07:27 -0700

ksrinivas,

ksrinivas wrote:                                                                 (Fri, 14 Feb 2003 10:24:50)
>    1. Is the T(pending) different from T(r)?. (If Yes, RFC / IG does not

Sorry, I meant T(r).

>    i.e., on the first ASP becoming Active?.

No, T(r) is started when moving to AS-PENDING stae.

>    should we send Notify(AS-Active)?.

On timeout of T(r) move to AS-INACTIVE and send Notify(AS-Inactive).

>    4. ASP should wait for NTFY(AS-ACTIVE) before starting traffic.

The ASP could, but it is not required or recommended to do so in the RFC.

--brian

---

From: ksrinivas <[email-masked]>
Date: Fri, 14 Feb 2003 11:53:49 +0530

Brian,

> No, T(r) is started when moving to AS-PENDING stae.

An AS is moved from AS-PENDING to AS-ACTIVE i.e., on the first ASP becoming Active. Should we wait till T(r) expires or n
number of ASP become Active in the AS-Active state itself?.
On T(r) expiry should we not start sending traffic to ASP, by sending Notify(AS-Active) and if required Notify(Insuff. ASP
resources)?.

---

From: ksrinivas <[email-masked]>
Date: Fri, 14 Feb 2003 12:12:16 +0530

Brian,

> On timeout of T(r) move to AS-INACTIVE and send Notify(AS-Inactive).

If one ASP is in ASP-Active state for n > 1 and T(r) expires, Should we not send Notify(AS-Active) and Notify(Insuff. ASP
Resources) to all the Inactive ASPs and send existing(bufferred) traffic by initiating the congestion procedures?.

This will be similar to the case of, an ASP going ASP-Inactive, causing lesser than n number of  ASPs to be in ASP-Active
state.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Feb 2003 23:54:24 -0700

ksrinivas,

ksrinivas wrote:                                                                 (Fri, 14 Feb 2003 12:12:16)
> If one ASP is in ASP-Active state for n > 1 and T(r) expires, Should we not
> send Notify(AS-Active) and Notify(Insuff. ASP Resources) to all the Inactive
> ASPs and send existing(bufferred) traffic by initiating the congestion
> procedures?.
> 
> This will be similar to the case of, an ASP going ASP-Inactive, causing
> lesser than n number of  ASPs to be in ASP-Active state.

One does not move to the AS-PENDING state until all the ASPs are ASP-INACTIVE
for the AS.  When T(r) expires, move to the AS-INACTIVE state as no ASPs are
active for the AS and the SG has waited long enough.

--brian

---

From: ksrinivas <[email-masked]>
Date: Fri, 14 Feb 2003 13:31:39 +0530

Brian,

> active for the AS and the SG has waited long enough.

My question is, While AS is in AS-Pending state, one of the ASP has sent ASP Active for n > 1 and timer has expired, i.e., number
of Active ASP are still less than n(but not 0). Do we still have to move to AS-INACTIVE?. IMO, We have to move AS state to Active
and send Notify(AS-Active) and Notify(Insuff. ASP Resources) to all the Inactive ASPs.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Feb 2003 01:35:57 -0700

ksrinivas,

ksrinivas wrote:                                                                 (Fri, 14 Feb 2003 13:31:39)
> My question is, While AS is in AS-Pending state, one of the ASP has sent ASP
> Active for n > 1 and timer has expired, i.e., number of Active ASP are still
> less than n(but not 0). Do we still have to move to AS-INACTIVE?. IMO, We
> have to move AS state to Active and send Notify(AS-Active) and
> Notify(Insuff. ASP Resources) to all the Inactive ASPs.

If the timer expired before the ASPAC, you are already in the AS-INACTIVE
state when the ASPAC arrived.  Then you would do the normal procedure from
the AS-INACTIVE state.  If the ASPAC arrives before the timer expires, the
timer is stopped and the AS-ACTIVE state entered.  Understand?

--brian

---

From: ksrinivas <[email-masked]>
Date: Fri, 14 Feb 2003 14:29:13 +0530

Brian,

>>If the ASPAC arrives before the timer expires, the timer is stopped and the AS-ACTIVE state >>entered.  Understand?

When Notify(AS-Active) has to be sent?. for the restart case also, do we have to wait for n number of ASPs to become
Active and then only resume the traffic by sending Notify(AS-Active)?.

--Srini

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Feb 2003 02:05:57 -0700

ksrinivas,

ksrinivas wrote:                                                                 (Fri, 14 Feb 2003 14:29:13)
> Brian,
> 
> >>If the ASPAC arrives before the timer expires, the timer is stopped and
> >>the AS-ACTIVE state >>entered.  Understand?
> 
> When Notify(AS-Active) has to be sent?. for the restart case also, do we
> have to wait for n number of ASPs to become Active and then only resume the
> traffic by sending Notify(AS-Active)?.

No, I think the RFC says to do that only from the AS-INACTIVE state, it doesn't
say to do that from the AS-PENDING state.  Moving from AS-PENDING to AS-ACTIVE
the Notify(AS-Active) should IMO be sent immediately.

If one wants to treat restart like start, set T(r) to 0 seconds.  Then the
AS-INACTIVE state is entered immediately and AS-PENDING could even be skipped.

--brian

---

From: ksrinivas <[email-masked]>
Date: Fri, 14 Feb 2003 14:45:35 +0530

Brian,

  I feel the things are pretty clear now. So what has to be done to section 3.15 in IG?.

--Srini.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Feb 2003 02:16:22 -0700

ksrinivas,

IMO section 3.15 of the IG just needs to be deleted.

--brian

ksrinivas wrote:                                                                 (Fri, 14 Feb 2003 14:45:35)

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 15 Feb 2003 10:22:02 -0800 (PST)

Hi Everybody,
> IMO section 3.15 of the IG just needs to be deleted.
Just to briefly summarize my opinion about n+k debate:
a)If nobody sees a need for n as mandatory, let's make
necessary changes(i.e. return to the old state
machine)

b)IMO, if n is to be interpreted as the engineered
value (but no mandatory) and the decision is to be
made by SG when traffic can flow between ASP/SGP, it
should be stated somewhere that NTFY(AS ACTIVE) is to
be interpreted by ASP to start traffic, because ASPs
can't decide when SG is going to decide that there are
enough ACTIVE ASPs for an AS.

c)IMO, it is unacceptable to have the statement that
ASPs SHOULD wait for n ACTIVE ASPs to start traffic,
if n is to be interpreted as in b). Because in this
case, SG can decide to start traffic before n ASPs are
ACTIVE, but ASPs will wait for n ACTIVE ASPs, so they
won't send traffic.

d)I would think, the most clean way is still to update
the transition from INACTIVE to ACTIVE in the very
first version of AS state machine by saying that SG
decides based on traffic conditions and on the number
of ACTIVE ASPs when this transition happens.

e)I don't know, whether there might be cases, where it
makes sense that ACTIVE to PENDING transition is also
decided by SG based on number of ACTIVE ASPs and
traffic conditions(intead of the last ASP going
INACTIVE)

    Tolga

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 15 Feb 2003 11:36:41 -0700

Tolga,

I have explained on this thread already the stop, start and
restart decisions.  Also, 'n' has always meant the number
required for engineered maximum load, you have simply
just mis-interpreted it.  Do not update the inactive to
active transition: it is adequately described in the RFC.

Strike IG section 3.15 an let the RFC be as it stands.

--brian

Tolga Asveren wrote:                     (Sat, 15 Feb 2003 10:22:02)