Subject: RE: [Sigtran] M3UA IG v04

From: "J.Javier Pastor (EE/EEM)" <[email-masked]>
Date: Fri, 11 Jul 2003 09:19:54 +0200

Hi Brian, 

Pls, see below some comments...

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: jueves, 10 de julio de 2003 14:36
> To: J.Javier Pastor (EE/EEM)
> Cc: [email-masked]'
> Subject: Re: [Sigtran] M3UA IG v04
> 
> 
> Javier,
> 
> 'n' is defined as the number of ASPs that are needed to handle
> the maximum engineered load of the AS.
> 
> This is the total load from the network correct?  As in the
> traffic delivered to the AS, from all SGP, all SG.  Correct?
> 
> What has that to do with the number of ASPs active for particular
> SGP?
> 
We are relying on SGPs to send all the load to the AS. Only when the AS gets to ACTIVE we are sure that it could afford all the load.

> There can be more than on SGP.  Correct?
> 
> There can be more than one SG.  Correct?
> 
> An ASP can be active for any number of SGPs in any number of 
> SGs.  Correct?
> 
> SGPs in an SG should be able to transfer traffic between 
> them.  Correct?

It basically depends on your implementation.
> 
> In general, what has the number of ASPs active for one SGP have
> to do with the traffic handling capacity of an AS?
> 
It has to do with the AS availability, a general rule in telephony nodes.

> 
> Consider the following (n+k == 2+0): (Figure 5).
> Consider first that SGP1 and SGP2 are in the same SG.
> 
> 
>      ________                  ________   
> ____|        |________________|        |
>     |  SGP1  |        ________|  ASP1  |
>     |________|       /        |________|
>      ________       /          ________
>     |        |_____/          |        |
> ____|  SGP2  |________________|  ASP2  |
>     |________|                |________|
> 
> 
Why don't you establish an assoc between SGP1 and ASP2 ?. This network design seems not to be very appropriate for the n+k=2+0

> 3.14 tells me that I SHOULD NOT direct traffic from the
> newtork from SGP1 to ASP1 on startup of ASP1 with SGP1.
> 
It is not recommended, but can always use smooth start. 

> Does that include passing traffic from SGP1 via SGP2?
> 
Nothing is said about that. Therefore it is not included.

> Is this because ASP1 cannot handle the load?
> 
It is because the AS has not sufficient resources to handle the expected traffic from SGP1

> What should SGP1 do?
Wait for more ASPs to become ACTIVE

> Now, consider that SGP1 and SGP2 are in different SGs.
> 
> Should SGP1 tell the network that the AS is inaccessible?
> 
It depends on what you call the network. If you refer to SS7, it is the SG's SPC the visible SPC, so SG will announce un/availability when needed.

> Should SGP1 direct traffic over C-links to SGP2 that will
> ultimately be the same a passing traffic to ASP1?
>
It may, if SGP1 has a route to reach SGP2. 
 
> Why should not SGP1 direct traffic to ASP1?
> 
It could do it when you uses smooth start. But it is not recommended since ASP1 could not handle all the load it receives...

> I don't think that 3.14 is very clear.  'n' has nothing to do
> with the handling capacity from a given SGP to an AS.  It has
> to do with the overall engineered maximum traffic that 'n' ASPs
> can handle for the AS.  In even the more trivial cases the SGP
> cannot follow the recommendation.
> 
It seems to me that the recommendation can be followed. Anyway I may be wrong. So if you can make another proposal that everyone agrees on, pls go ahead.

Cheers // Javier.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 11 Jul 2003 02:36:44 -0600

J.Javier,

J.Javier Pastor (EE/EEM) wrote:                                                   (Fri, 11 Jul 2003 09:19:54)
> We are relying on SGPs to send all the load to the AS. Only when the AS gets
> to ACTIVE we are sure that it could afford all the load.

What has that to do with the number of ASPs active for a
particular SGP?

'n' is a system value, not a per-SGP value.  The AS state
machine in the IG treats 'n' as a per-SGP value, when it is
defined as a system value.

What has the number of active ASPs for an SGP (the per-SGP
value) have to do with the number of active ASPs for the AS
(system value)?

An SGP cannot tell how many ASPs are active for the AS (system
value), just the number of ASPs that are active to it (per-SGP
value).

How can one count active ASPs for the SGP (per-SGP value) and
compare it to 'n' (the system value)?

> Why don't you establish an assoc between SGP1 and ASP2 ?. This network
> design seems not to be very appropriate for the n+k=2+0

It's a simple example.  The association between SGP1 and ASP2
happens to be down at the moment.

> It is not recommended, but can always use smooth start. 

On what grounds can you not recommend directing traffic above?
There are suffcient ASPs active fo the AS (system value) to
handle the maximum engineered load.  'n' of them are active for
the AS (system value), SGP1 has 1 of them active to it (per-SGP)
value.

Please tell me what number you are expecting the SGP to use: the
system value?  or the per-SGP value.

> Nothing is said about that. Therefore it is not included.

Silence implies acceptance.  If you only want to say that the
SGP should not direct traffic towards the ASP directly over the
association between the SGP and the ASP, please say so.

> It is because the AS has not sufficient resources to handle the expected

But it does in the diagram.  Two ASPs are active for the AS and
handling traffic for the AS.  There are 'n' ASPs handling
traffic and they can handle the maximum engineerd load.

So there ARE sufficent resources to handle the expected load.
It is just that SGP1 cannot discern that from the number of ASPs
active to it alone.

> Wait for more ASPs to become ACTIVE

Why? There are 'n' ASPs already handling traffic!

> It depends on what you call the network. If you refer to SS7, it is the SG's
> SPC the visible SPC, so SG will announce un/availability when needed.

> It could do it when you uses smooth start. But it is not recommended since
> ASP1 could not handle all the load it receives...

Look at the diagram.  ASP1 is already exposed to full load via
SGP2.  So is its not true that ASP1 cannot handling the load,
because it is already exposed to it via SGP2.

Also, what do you mean by "could not handle all the load it
receives..."?  An MTP-User (AS) must have overload controls to
address traffic overloads at any time.

Are you advocating that ASP are to be built to not conform to
SS7 specifications in this regard?

Is your ASP not able to handle overload?

Is there anyone on the list whose ASP is not able to handle
overload traffic?

> It seems to me that the recommendation can be followed. Anyway I
> may be wrong. So if you can make another proposal that everyone
> agrees on, pls go ahead.

If you mean to count per-SGP APSs and compare the number against
the system-wide engineered value 'n', then every time that the
number of ASPs active for an SGP is different from the number of
ASPs active for the AS (system wide), there will be a problem.

In systems where 'n' are active and 'k' are (cold) backup, every
time that an ASP cannot activate to a given SGP, that SGP is out
of service (as in the above trivial example).

Also, the recommendation is based on the premise that the ASP
cannot handle overload in thes start scenario (where it
obviously is able to handle it in the restart scenario).  This
is a contradiction.  Either the ASP is capable of handling
overload or it is not.

I have asked many times now, and nobody will say that their ASP
cannot handle overload.

The recommendation is technically invalid because of the
following:

1. The number of ASPs active at an SGP (per-SGP) is not the
   number of ASPs active for the AS (system value 'n').

2. ASPs must be able to handle overload, because they must
   conform to SS7 standards.

In the current RFC, it there are ASPs so badly designed that
they cannot handle an overload, they should take care with how
they activate.  They SHOULD coordinate amoung themselves that
'n' are active.  If 'n' ASPs cannot be brought to the ASP-ACTIVE
state for the AS, then none of the ASPs need activate.

Relying on this, more sound, recommendation, the SGP can
activate with the first ASP, knowing that 'n' of them have been
coordinated to become active.

In this way, in the current RFC, the ASP assures that SGP that
'n' are to be active on a system basis (which only the ASPs can
know, and because they have coordinated amoung themselves).  So
the SGP can activate on the first ASP on a per-SGP basis.

The current RFC also allows the SGP to wait further if it has
some additional information about the sufficiency of the number
of active ASPs in addition to the assurance that there will be
'n' active or the first one would not have activated.

The current RFC provides a way around your counting problem, and
even accommodates broken ASPs that can't conform to SS7 overload
controls.  It also leaves the activation of the AS squarely on
the shoulders of the ASPs, where it belongs, and the SGP just
does what it is told.

So, by the RFC, in the above example, when ASP1 activates with
SGP1, SGP1 already has the assurance that ASP1 has coordinated
with ASP2 that both of them will become active.  Thus it can
activate the as immediately.  It also MAY consider that SGP2 has
ASP2 already active as verfication that there are sufficient
ASPs active in the AS, or wait until some SGP has ASP2 active
if, for example, it shares state amoung SGP. to that extent.

So, perhaps not so strangely, the recommendation in 3.14 for the
example above, stops SGP1 from activating the AS when it is
completely reasonable for it to do so.  The RFC, on the other
hand, has SGP1 activating correctly.

I think you need to alter your proposal so that SGP1 can
activate immeidately in the example above, on recommendation
and not option.

You are welcome to go back to the wording in the RFC ("MAY
withhold" instead of "SHOULD NOT direct") to correct this
problem.  Of course, then there would be no need for all the
'n' stuff in the AS state machine.

--brian

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

---

From: "Samuel Dur D. Jeyaseelan" <[email-masked]>
Date: Fri, 11 Jul 2003 03:56:12 -0500 (CDT)

Brian,

See comments inline.

--Samuel

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

> > > the maximum engineered load of the AS.
Incorrect. RFC says in section 1.4.4.1
    
   The failover model supports an "n+k" redundancy model, where "n" ASPs
   is the minimum number of redundant ASPs required to handle traffic
          -------
   and "k" ASPs are available to take over for a failed or unavailable
   ASP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 11 Jul 2003 03:17:53 -0600

Samuel,

Samuel Dur D. Jeyaseelan wrote:                                                     (Fri, 11 Jul 2003 03:56:12)
>    and "k" ASPs are available to take over for a failed or unavailable

I was talking about the IG (as in the subject line).  The IG says:

   As "n" ASPs are needed to handle the maximum engineered load of the
   AS, ...

--brian

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