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

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Wed, 18 Jun 2003 08:43:00 -0500 (CDT)

Brian,

 Just going back to 25-Feb-2003 ....

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

> Samuel,
> 
> Samuel Dur D. Jeyaseelan wrote:                                                     (Tue, 25 Feb 2003 03:56:07)
> > 
> > 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
> 
> I agree.   That is what is provided for in the RFC.  However, section 3.15 of
> the IG would require the SG to stop traffic when n < 2.  So, it must be
> struck.
> 
> --brian
[Samuel] Does new IG stop the traffic when n < 2 ?

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Jun 2003 12:39:39 -0600

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Wed, 18 Jun 2003 08:43:00)
> [Samuel] Does new IG stop the traffic when n < 2 ?

Yes, it does.  On restart.

--brian

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Wed, 18 Jun 2003 22:48:23 -0500 (CDT)

Brian,

> Yes, it does.  On restart.
Yes thats what everybody agrees that on start and restart case 'n' number
of ASPs to be in ACTIVE state.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Jun 2003 22:54:40 -0600

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Wed, 18 Jun 2003 22:48:23)
> of ASPs to be in ACTIVE state.

Disagree wholeheartedly.  And this was never agreed.

What was agreed (except for Tolga) was that the RFC allowed the SG to either
activate on one ASP or wait for 'n' and withhold NTFY(AS-ACTIVE) which was
sufficient for both start and restart cases.

If an outage has been for a brief period and was not congestion related, there
is no reason why traffic cannot be started on the first active ASP, or under
emergency conditions for that matter.

The start, restart and shutdown decisions were discussed in detail on the
list.  Whether the SG waits for 1 or 'n' is an IMPLEMENTATION and OPERATIONAL
decision.  The existing RFC provides for this in saying that the AS-ACTIVE
state implies that "at least one" ASP is in the ASP-ACTIVE state for the AS.
Also the RFC states that the SGP should withhold the NTFY(AS-ACTIVE) until 'n'
ASPs are active if it is going to wait for 'n' ASPs (as it MAY do).  And it
also says that the ASPs should coordinate amoungst themselves to ensure that
'n' are active.

Let me give you an example of the negative effect of this change:  An SG is
configured with n=256.  There are 257 ASPs.  2 are dead.  The AS will never
activate.  Some carrier class system...

Contrast this where, soley at the SG implementer's discretion, the SG
implementor sets a timer when the first ASP goes ASP-ACTIVE for the AS.  If
the other 255 are not active by the time this timer expires, it sends
NTFY(AS-ACTIVE) and starts traffic.  This system will always come up in
contrast to the above that will not.  The RFC allows for this system, the
new IG text does not.

The new IG text would have you implement the system that will never come up
with 2 ASPs out of service.  The RFC does not.

I you wan to explain things in the IG, go ahead, but the proposed text does
not do that.  The proposed text makes changes to the normal and correct
operation as laid out in the RFC and starts making implementation and
operational decisions for the SG designer that it must not.

--brian

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 19 Jun 2003 00:42:05 -0500 (CDT)

Brian,

> sufficient for both start and restart cases.
section 5.4.1 says that minimum 'n' number of ASPs are required to handle 
total traffic load.Here my understanding is, craft person knows the
incoming traffic capacity based on some kind of 'traffic measurement
analysis',
and the same time craft person knows, to handle this incoming traffic an
SGP requires 'n' ASPs.Here the point is craft person can not maintain 'n'
ASPs to be in ACTIVE state throughout the traffic period but at least he
can make sure 'n' ASPs are ACTIVE when (initally) SG comes up.

> emergency conditions for that matter.
This may happen while SGP is processing the load but it may not happen in
the beginning and a good network configuration should not allow these
kinds of problems to happen in the beginning.

> also says that the ASPs should coordinate amoungst themselves to ensure that
This is left to the decision of the craft person, this case he can
configure n=1.
> activate.  Some carrier class system...
If n=256, it is the responsibility of the operator to make sure and bring
up 256 ASPs to ACTIVE state at least in the beginning.

> with 2 ASPs out of service.  The RFC does not.

section 5.1.4
   n+k case
   --------
   This scenario shows the example M3UA message flows for the
   establishment of traffic between an SGP and three ASPs in the same
   Application Server, where two of the ASPs are brought to the state
   ASP-ACTIVE and subsequently share the load.  In this case, a minimum
   of two ASPs are required to handle the total traffic load (2+1
   sparing).

still RFC says '... a minimum of two ASPs are required to handle the total
traffic load ....'

> operational decisions for the SG designer that it must not.

I have conveyed my understanding to all. Otherwise in order to conclude 
this issue we can go for polling.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Jun 2003 01:38:18 -0600

Samuel,

'n' (as agreed by concensus, and included in the new IG text as well) is the
number of ASP required to handle the "maximum engineered load", not the normal
load, or event the expected load.  So, for an ISUP bearing system, if it is
not Christmas or Mother's day, and there is not a significant backlog of
reattempt traffic (extended outage), the system can come up with less than 'n'
processors, as 'n' is defined.  Therefore, refusing to start or restart an
AS with less than 'n' active ASPs is foolish.

Setting n to 1, as you suggest, would be incorrect.  1 ASP cannot handle the
"maximum engineered load".  In the example, it takes 256 ASPs to handle the
"maximum engineered load" (e.g. busy-hour on Mother's Day).  But for the other
340 some days of the year, some lesser number of ASPs is sufficient, and 255
ASPs is surely sufficient.

Not permitting the SG to start or restart with less than 'n' ASPs active
is a bad thing for carrier class systems.

I cannot agree with the change on these grounds.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 19 Jun 2003 00:42:05)

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Thu, 19 Jun 2003 06:56:10 -0500 (CDT)

Brian,

                        +----+                  +-----+
                        |STP-|------------------| ASP1| SCP (1-1-1)
     +------------------| SG |------+           +-----+
     |                  +----+      |  
     |                              |           +-----+
     |                              +-----------| ASP2| MGC(2-2-2)
     |                                          +-----+
     |                      
 Conventional SS7

Consider a call which needs to access database (ASP1) and then
to be routed to ASP2.
In this case if we configure n=2 and 'n' as a mandatory,then
the call will pass. This same will fail if n is not a mandatory
as SG started processing the traffic as soon as one of the ASPs
becomes available.The unavailability of another ASP will
fail the call.

So we need to have certain restrictions to make 'n' as mandatory
to process the call successfully.

--Samuel

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 19 Jun 2003 05:26:46 -0700 (PDT)

Brian,
--- "Brian F. G. Bidulock" <[email-masked]>
> ASPs is surely sufficient.
[TOLGA]For this case, IMO n=1 (or whatever is the
number of ASPs, which should be ACTIVE at minimum)is
correct. I don't interprete n as number of maximum
ASPs, which can be ACTIVE at any given time. n is the
number of ASPs, which should be ACTIVE, so that AS
switches to ACTIVE state. For example, if n=3, this
IMO does not mean that I can't have 256 ASPs ACTIVE at
any given time. So, for your example, you set
n=sufficient number of ASPs(something less than 256). 
Maybe using the term n+k for this kind of operation is
what you don't like?
> Samuel Dur D. Jeyaseelan wrote:                     
>                                (Thu, 19 Jun 2003
> 00:42:05)
> > 
> > Brian,
> > 
> > 
> > > Samuel Dur D. Jeyaseelan wrote:                 
>                                    (Wed, 18 Jun 2003
> 22:48:23)
> > > > > > > 
=== message truncated ===

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Jun 2003 13:17:04 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Thu, 19 Jun 2003 05:26:46)
> Maybe using the term n+k for this kind of operation is

But that would change the meaning of 'n' from the agreed
"maximum engineered load".

--brian

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Jun 2003 13:44:32 -0600

Samuel,

These are two different AS.  'n' is an AS specific number.

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Thu, 19 Jun 2003 06:56:10)

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 20 Jun 2003 01:23:19 -0500 (CDT)

Brian,
 Yes i understood 'n' is an AS specific number. But i have a freedom to
comprise ASP1 and ASP2 in one AS having a single point code.It is just a
matter of configuration.Ultimately i want to say SGP needs both ASPs to be
be in ACTIVE state to process a given explained call.

--Samuel

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Jun 2003 02:10:44 -0600

Samuel,

So, why do your ASPs have different point codes in the diagram?

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Fri, 20 Jun 2003 01:23:19)

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 20 Jun 2003 04:26:25 -0500 (CDT)

Brian,
I meant to say ASP1 and ASP2 are in a single SPMC which has a single point
code.

--Samuel

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 20 Jun 2003 04:30:59 -0700 (PDT)

Brian,

[..snip..]
> "maximum engineered load".
[TOLGA]To be honest, if the agreement is to interprete
n as the maximum number of ASPs, which can be ACTIVE
at any time, I disagree with this -and yes IMO
"maximum engineered load" might be a misleading term
for n-. But I think, the way of operation explained
above is reasonable, and probably what people would
agree in general(?). IMO, the importance of n from
M3UA point of view is, that based on n, AS state
change to ACTIVE happens -so it is more "minimum
number of required ASPs".

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Jun 2003 06:49:10 -0600

Samuel,

Could you, then, please explain how your example has anything to do with 'n'?

--brian

Samuel Dur D. Jeyaseelan wrote:                                                     (Fri, 20 Jun 2003 04:26:25)

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Jun 2003 06:54:51 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 20 Jun 2003 04:30:59)
> number of required ASPs". 

No such thing as "minimum number of required ASPs"
in carrier class systems.  Such an 'n' could not be
anything other than 1.

There is such thing as the minimum number of ASPs
required to handle the "maximum engineered load".
Such an 'n' can be greater than 1, and an SG cannot
be required to remain inactive when so much as 1 ASP
is active.

The latter is what the RFC already provides.  The IG
attempts to deviate from that without apparent cause
or purpose.

Please tell me: what bad thing do you think will
happen if the RFC is followed as it stands?

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 20 Jun 2003 06:13:11 -0700 (PDT)

Brian,
wrote:
> Tolga Asveren wrote:                                
>                                 (Fri, 20 Jun 2003
> 04:30:59)
> > > > ASPs, which can be ACTIVE at any given time. n
> is
> > > the
> > > > n=sufficient number of ASPs(something less
> than
> > > 256). 
> > > But that would change the meaning of 'n' from
> the
> > > agreed
[TOLGA]It is obvious that RFC as it stands now is
WRONG, regarding n+k mode. Parts of it are written
without considering n>1 case. Now, if one thinks that
always n=1 (n being used as I refer above, i.e.
minimum number of ACTIVE ASPs to declare AS as
ACTIVE-)
then this is easy to achieve with IG, just use always
n=1. If one interpretes n as you describe -the value
to be used during mother's day-, IMO n has nothing to
do with M3UA AS state machine -so no need to mention
anything about it in M3UA documents-, something
totally different. 
The important thing IMO is that ASPs and SGPs have the
same AS state view. And to achieve this, when staet
change to ACTIVE for AS  happens, should be clearly
defined. RFC fails on this. Now, about the bad thing,
which can happen if this view is not the same, -as I
stated several times- SG might expose AS as available
to SS7 network, whereas in fact in wasn't available.
Nodes in SS7 domain will send traffic to AS but can't
get replies. This, IMO should be avoided.
Basically, I could understand if somebody advocates
the idea that n+k mode is useless (because n is going
to be always 1), but this would require striking out
everything related with n+k in both IG and RFC, not
just IG (and IMO because n+k mode includes n=1, there
is no need to put restrictions. For example, it migth
be usefull for a case, where the operator does not
want AS to be ACTIVE, unless two ASPs are ACTIVE, to
ensure redundancy at the startup. IMO, the value of n
is an operation issue)
IMO, the only thing, which could be modified in the
proposed text is not to use the term "maximum
engineered load", and explain maybe more openly, what
is meant with n.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Jun 2003 14:33:35 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 20 Jun 2003 06:13:11)
> WRONG, regarding n+k mode.

Where is it WRONG?

> Parts of it are written
> without considering n>1 case.

Which parts?

> Now, if one thinks that
> n=1.

Even the IG defines 'n' as the mininum number of ASPs
for "maximum engineered load".  So you would further
change the definition of 'n' again?  We already agreed
by concensus that 'n' was the minimum numebr of ASPs
for "maximum engineered load".

> If one interpretes n as you describe -the value

This was the concensus reached from the last discusssion.
If you don't care about such a definition of 'n' then
you shouldn't need to get further involved in these
dicussions.

> defined.

It is: SGP MUST send NTFY(AS-ACTIVE) when it moves the
AS to the AS-ACTIVE state.  This is provided for in the
RFC.  The ASP ALWAYS knows when the SGP determines that
an as is active from its view.

> RFC fails on this.

Simply wrong.  The SGP sending NTFY(AS-ACTIVE) ensures
that the SGP and ASP have the same view of AS state,
and not just for the AS-ACTIVE state.

> Now, about the bad thing,
> which can happen if this view is not the same,

Because of NTFY(AS-ACTIVE) the view cannot differ, so
no bad thing can happen based on mis-match of state.

> -as I

Can't happen.  Please try to describe an example message
flow in terms of M3UA messages.

> get replies.

Can't happen.  Please try to describe an example message
flow in terms of M3UA messages.

> This, IMO should be avoided.

It can't happen under exisint RFC.  This is precisely
why the NTFY(AS-ACTIVE) is withheld if the SG is going
to wait for 'n' ASPs to activate.  So that this can
never happen.

> ensure redundancy at the startup. IMO, the value of n

The existing RFC has the ability for the SGP to wait
for 'n' where n>1 and withhold NTFY)(AS-ACTIVE).  You
will not be removing this option either.

> engineered load", and explain maybe more openly, what

The only thing to do is scrap the proposed text.  The
SGP must be permitted to activate the AS with the first
ASP (and send NTFY(AS-ACTIVE) immediately) or activate
the AS with the 'n'th ASP (sending NTFY(AS-ACTIVE) only
after the 'n' ASP) or at some 'm' value or time expiration
somewhere in between.  It is the ASPss responsibility to
coordinate amongst themselves and get 'n' 0f them up.
If the APS needs 'n' or nothing, it should not activate
until it can be sure that n-1 other ASPs are also
activating.

This is what is already provided for in the RFC, regardless
of what one's view of 'n' is, the SGP is provided the option
to do the right thing, and the requirement to notify the
ASP of its decision (with NTFY(AS-ACTIVE)).

The only thing left to do is strike 3.15.

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 20 Jun 2003 13:50:08 -0700 (PDT)

Brian,

1- NTFY has only advisory meaning, there is no
"SHOULD" action, which is to be taken after NTFY, so
your argument that ASPs can rely on NTFY is not valid
-you know it was proposed to make ASPs decide for the
AS state change by NTFY but it was not accepted,
because it was considered as a too radical change-.
Nowhere it is stated in RFC nor in IG, that ASPs
decide to accept/receive application traffic based on
NTFY.

2- RFC tells that ASPs SHOULD arrange number of ACTIVE
ASPs among themselves, but allows SG to start routing
traffic even with less than n ACTIVE ASP. Just look to
the definition of INACTIVE AS in RFC, an AS whith no
application traffic flowing to/from it. So, they might
have inconsistent views of AS state.

3- If n is to be seen as the mother day's value, IMO
it really has nothing to do with M3UA, because it
won't change AS state at all (or maybe you can give an
example about its relation to M3UA)

    Regards,
     Tolga  
wrote:
> 06:13:11)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Jun 2003 16:14:13 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 20 Jun 2003 13:50:08)
> your argument that ASPs can rely on NTFY is not valid

The RFC does not say that.  It says:

  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.

And the ASP can rely on it.  The Notify is advisory.
The ASP can ignore it if it likes.  It does not
compel the ASP to do anything.  The ASP can ignore
the notification of AS state change at its own peril.

The argument that an ASP can rely on this notify is
ensured by the SHOULD in the passage above.

> AS state change by NTFY but it was not accepted,

That was an observation in an old thread, not a
rejection.

The ASP is welcome to use whatever information it
has at its disposal, INCLUDING Notify, which it can
rely upon because of the requirement (MUST) for the
SGP to send it.

> because it was considered as a too radical change-.

What change?  It is already there in the RFC in
section 4.3.4.3.  This is also true for M2UA and
SUA.

> decide to accept/receive application traffic based on

There is no requirement for them to do so.  There
is, however, a requirement placed on ASPs in thes
same section (4.3.4.3) that reads;

  For the n+k redundancy case, ASPs which are in the
  AS SHOULD coordinate amoung themselves the number
  of active ASPs in the AS, and should start sending
  traffic only after 'n' ASPs are active.

It does not require the ASP to use Notify, but it
does not keep the ASP from using whatever means it
has at its disposal for coordinating that 'n' ASPs
become active.
> traffic even with less than n ACTIVE ASP.

As it should.

> Just look to

No, because the ASP will coordinate that 'n' are
active.

> example about its relation to M3UA)

I think you misread the first quote from 4.3.4.3.
The ASP has little idea what load it will be offered
when it activates.  This is why it should coordinate
that 'n' are active.  It might be Mother's Day, it
might not.  The SG, on the other hand, has a better
idea of what load will be offered and will activate
when the number of ASPs is sufficient to handle the
load.  That is not necessariliy 'n'.  'n' is just an
example in the quote: "(e.g., until thare are "n"
ASPs in state ASP-ACTIVE in the AS)".  The SG
normally activates the AS with the first active ASP
(as indicated and completely consistent with the
state diagram and descriptions in the RFC), but it
MAY wait until 'n' are active.  In any case it sends
Notify to indicate that th AS is active as it MUST
(see the MUSTs in section 4.3.4.5).

It is not a question that the SGP MUST send Notify.
It MAY wait until sufficient ASPs are active to
handle the load (and not necessarily "n", but it may
be "n") and it SHOULD withhold the Notify until
sufficient ASPs are active to handle the load.

This provide the SG designer with the freedom to
meet dynamic load and redundancy needs at the same
time as ensuring interoperability through the Notify
and ASP-Active procedures.

You seem to want to restrict this further, taking
the necessary flexibility away from the SG designer
with no resulting benefit.  I cannot agree with the
proposal.  The RFC is both sufficient and necessary
in this regard.

Strike 3.15.

--brian

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

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 24 Jun 2003 10:59:53 -0700 (PDT)

Brian,

Although I do not believe that it will help us to
reach a consensus , still I will try to summarize my
opinions about this topic -otherwise I think we just
have different opinions/interpretations about text and
in the last messages I am just repeating the same
things again and again and wasting bandwith-

1- My interpretation of "ASPs coordinating n ACTIVE
ASPs among themselves" is not that they rely on NTFY,
but they do this via some communication inside ASP
cluster. And even if one could argue that NTFY might
be used for this, unless it is mandated in the
document, it has little value IMO (in fact this is the
key point, you assume that NTFY is going to be used
for this purpose). I can have a RFC compliant ASP,
which does not coordinate n based on NTFY. So, based
on that, I think the only way to synchronize AS staet
changes on ASP and SGPs is a)either using NTFY -this
is not mandated in RFC- b)or to rely on a
preconfigured number n . Relying on n requires, that
both sides know this number and activate AS only after
n ASPs are ACTIVE.

2- In my opinion it questionable, whether SG or ASPs
have a better view about current load/load to be
offered on ASPs -especially considering that ASPs
might serve multiple AS and can be connected to
multiple SG-. When the AS is not ACTIVE, SG also won't
receive traffic for it, so it seems to me that it
can't decide based on traffic dynamics to activate an
AS or not. Furthermore, as I said above, SG is even
not aware of the current load on ASPs. Yes, n is
static, but IMO it is operators responsibility to
activate more ASPs when needed -manually or via a
monitoring program etc...- . So for me, using n=1 (or
whatever is the needed minimum number of ASPs) and
activating new ASPs during mother's day is a valid
solution -and I think those new ASPs activated for
mother's day have nothing to do with M3UA itself, just
an operational issue-  

    Tolga 
wrote:
> 13:50:08)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 24 Jun 2003 12:17:45 -0600

Tolga,

The RFC permits an SG to wait until sufficient
resources are active before directing traffic to
the ASP as you describe.

There is no reason, however, to require the SG
to wait.

It appears to me that the RFC accomodates your
view, but also accomodates other views (AS
active on first ASP).  If your ASPs can indeed
coordinate 'n' amoung themselves, then it is
moot what the SG does.

IG 3.15 attempts to force the optional procedure
in the SG, of waiting until sufficient resources
are active, to be a mandatory procedure.  (The
changing of MAY to MUST that I have always
disagreed with.)

What need is there to force your view on others
when, as you say, your ASPs can coordinate that
'n' of them are active, anyway?

--brian

Tolga Asveren wrote:                                                                 (Tue, 24 Jun 2003 10:59:53)

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

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 24 Jun 2003 13:54:50 -0700 (PDT)

Brian,
(some more repeating of my ideas about this topic ;-)
)
--- "Brian F. G. Bidulock" <[email-masked]>
> There is no reason, however, to require the SG
[TOLGA]Basically, what you are describing is "Let SG
decide by itself, when to activate AS". In such a
case, there should be a mechanism for SG to tell about
this state change, which will make the ASPs to change
their AS state accordingly -IMO, NTFY, as decribed in
RFC can't be seen as serving this purpose, as it is
not mandatory that ASPs update AS state based on
that-. I also doubt, whether SG can dynamically decide
when to activate AS, while it does not receive traffic
for AS.
> coordinate 'n' amoung themselves, then it is
[TOLGA] IMO it is not irrelevant what SG does, if ASPs
coordinate 'n' among themselves -not based on NTFY-.
In such a case, it might happen that SG switches AS
state to ACTIVE with less than n ACTIVE ASPs but ASPs
will still wait for n ASPs to become ACTIVE and will
have AS state INACTIVE. The result will be SG exposing
AS as available to SS7 network, while in fact it was
not ready on ASP side, this IMO shouldn't happen. 
> 'n' of them are active, anyway?
[TOLGA]IMO, it is important that AS states are
consistent on both sides(so the goal is not to put
restrictions).
Secondly, if SG does not see AS as ACTIVE, there
shouldn't be traffic directed for this AS to this SG.
So, which traffic is SG supposed to withhold?
Initially SG should see AS as ACTIVE -before there was
any traffic-, and this IMO can be decided only based
on number of ACTIVE ASPs -where this number can be
also 1 of course-.
>                                 (Tue, 24 Jun 2003
> 10:59:53)
> > >                                 (Fri, 20 Jun
> 2003
> > > > "SHOULD" action, which is to be taken after
> NTFY,
> > > so
> > > > your argument that ASPs can rely on NTFY is
> not
> > > valid
> > > 
> > > > -you know it was proposed to make ASPs decide
> for
> > > the

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 24 Jun 2003 15:24:49 -0600

Tolga,

Tolga Asveren wrote:                                                                 (Tue, 24 Jun 2003 13:54:50)
> when to activate AS, while it does not receive traffic

NTFY serves this purpose.  Whether your ASP
relies on it or not is up to the ASP designer.
You say your ASPs can coordinate 'n' without
relying on NTFY, so there is obviously no need
for any extra protocol to signal this.

> not ready on ASP side, this IMO shouldn't happen. 

Here's where your wrong.  Activating an AS and
traffic from the SS7 network are not correlated.
There is no requirement to direct traffic after
AS-ACTIVE.  When the SG indicates SS7 network
availability is a function of the NIF and there
are no requirements in the RFC in this regard.
Also, even after the NIF decides to place the PC
or UP as available, there will be some
considerable time before traffic will start.
Distant signalling points and user parts will
have to time out on procedures before they will
restart traffic.  If an SG chooses to do this on
the first active ASP (getting a jump on restart
and knowing that it will take some time for
traffic to resume, and knowing that the APSs
will coordinate 'n' amoungst themselves anyway)
the is is allowed to do so by the RFC, but not
by the IG 3.15 proposal.

> consistent on both sides(so the goal is not to put

It is not so important.  Procedures are in place
to resynchronize state.  One of the most
important ones is the Notify procedure.  The SG
MUST notify ASPs of its perceived state for the
AS.  It is not an option.  The ASP can rely on
this because it is an absolute requirement.  (MUST)

> shouldn't be traffic directed for this AS to this SG.

The timing of traffic and AS activity is not
correlated or specified.  This is an NIF
function.  The SG cannot decide WHEN to resume
traffic, it is the remote signalling point that
decides WHEN to resume traffic.

By "direct traffic" the RFC means: do that NIF
thing to allow remote signalling points to
resume traffic at some time in the future.

> So, which traffic is SG supposed to withhold?

The SG does not withhold traffic, it withholds
the NTFY)(AS Active) if it waits to do that NIF
thing until it is confident that there are
sufficient ASP resources active to handle some
future load.  But this must remain optional.
The SG must be permitted to do that NIF thing on
the first active ASP (or 'm'th" or after a timeout) or
whenever it deems necessary after the first
active ASP.  And this cannot be mandated as 'n'.

> on number of ACTIVE ASPs -where this number can be

No. The SG can do that NIF thing in anticipation
of 'n' ASPs being active because it has the
knowledge that 'n' will become active because
the ASPs SHOULD coordinate that 'n' are active.

There is no problem with the existing RFC.

Mandating 'n' is unacceptable.

I will ask you once more the question that you
have neglected to answer:

What bad thing will happen if the SG activates
(does that NIF thing) on the first ASP and the ASPs
wait until 'n'?

Quite frankly there is no bad thing that will
happen and therefore all interoperability needs
are met by the existing RFC.

--brian

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