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

From: "Srivats P." <[email-masked]>
Date: Tue, 25 Feb 2003 11:18:36 +0500

All,

Where do we go from here on this one ? Should we put it to a vote or
something ?

IMO, not stopping traffic when #ASPs < n makes more sense to me ...
however since different people are reading it in different ways ...
the IG should clarify this point.

Regards,
Srivats

At 19/02/2003 3:30:00 AM, you wrote:
>
>Hi,
>
>I beleive 'n' is minimum number of ASPs to handle the 'best traffic T'.
>To handle the 'worst traffic T+1', SG may require 'n+1' ASPs.
>
>'n'is the derived value based on the traffic report given by Traffic
>Metering and Measurement.
>
>So 'n' is fed during configuration of stack.When traffic increases from
>'T' to 'T+1' or # APSs < n - this case SG is required to send NOTIFY to
>'k' ASP.
>
>And one more thing when # APSs < n, SG still can handle the traffic with
>single ASP.
>
>When 'n' ASPs are active
>------------------------
>
>SLS-X  ---->ASP1
>SLS-Y  ---->ASP2
>
>When ASP1 goes down
>-------------------
>
>SLS-(Y,X)  ----->ASP2
>
>Instead of banning the complete traffic ,it can be handled (not 100%) by
>ASP2.
>
>
>--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. *******
>
>On Tue, 18 Feb 2003, Javier Pastor-Balbas (ECE) wrote:
>
>> Brian, 
>> 
>> I agree 
>> 
>> RFC simply says: 
>> 
>> 	"n ASPs is the minimum number of redundant ASPs required to handle traffic"
>> 
>> As this is the minimum number, it can be inferred that for #ASPs < n no traffic can be handled. Nothing is mentioned in the RFC about 
engineered load although it may be thought that n value calculation is based on that.  
>> 
>> I would say that the current model does not support the use of extra ASPs for loads bigger than the engineered nor the use of less than n 
for smaller loads... The message is clear saying that #ASPs<n implies no traffic, i.e. whenever you can not support
> the engineered load, stop the system. This last sentence is not in the RFC but it can be deduced as the engineered load for n can... 
>> 
>> Cheers // Javier. 
>> 
>> > -----Original Message-----
>> > From: Brian F. G. Bidulock [mailto:[email-masked]]
>> > Sent: Tuesday, February 18, 2003 12:49 PM
>> > To: Javier Pastor-Balbas (ECE)
>> > Cc: [email-masked]
>> > Subject: Re: [Sigtran] Re: M3UA Notify message
>> > 
>> > 
>> > Javier,
>> > 
>> > Javier Pastor-Balbas (ECE) wrote:             (Tue, 18 Feb 
>> > 2003 12:17:54)
>> > > > Javier Pastor-Balbas (ECE) wrote:             (Tue, 18 
>> > Feb 2003 07:57:23)
>> > > > > 
>> > > > > Hi Brian, 
>> > > > > 
>> > > > > According to the RFC "n" is required to handle traffic 
>> > with minimum
>> > > > > losses, what is expected from the SS7 point of view in 
>> > an interworking
>> > > > > scenario.
>> > 
>> > Please cite this passage, because I cannot find it.  I find 
>> > no mention of
>> > minimum number of ASPs and "message loss".  The only 
>> > reference to message loss
>> > that I know of is unrelated.
>> > 
>> 
>> 
>> 
>> > > > 
>> > > > That would be the numbe required to handle maximum 
>> > engineered load, which
>> > > > is the same thing.
>> > > > 
>> > > 
>> > > If you refer to the compromise load engineered to be 
>> > available 99% (aprox.)
>> > > of the time, then I agree. But this is a statically value fed at
>> > > configuration time. And the system won't work till n number 
>> > is reach since
>> > > the system will likely have quality contrains.
>> > 
>> > The maximum engineered load is a figure established at 
>> > configuration time.
>> > 
>> > Carrier-grade systems must always work with 1 processor.  The 
>> > system will just
>> > not necessarily be able to handle the offered load.  (But it might:
>> > particularly during quiet periods, off-peak, normal-day, etc.)
>> > 
>> > The offered load cannot be established at configuration time 
>> > and varies widely
>> > for telephony systems.
>> > 
>> > You must also realized that the system might, at any time,  
>> > be offered a load
>> > greater than the maximum engineered load (mass calling, busy 
>> > periods, etc.):
>> > so for carrier-grade systems even "n" processors must 
>> > implement overload
>> > controls (and they could not claim SS7 compliance if they didn't).
>> > 
>> > Look back in this thread and you will see the factors 
>> > contributing to the
>> > anticipated offered load for the start, restart and stop decision.
>> > 
>> > The decisions are not based on less than "n" processors not 
>> > allowing the
>> > system to work (where n > 1).  They are based on the negative 
>> > effects of
>> > delivering pent up traffic to processors that will likely 
>> > just congest.
>> > 
>> > --brian
>> > 
>> > -- 
>> > Brian F. G. Bidulock
>> > [email-masked]
>> > http://www.openss7.org/
>> > 
>> _______________________________________________
>> Sigtran mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/sigtran
>> 
>
>_______________________________________________
>Sigtran mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/sigtran
>

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

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 26 Feb 2003 09:01:07 +0100

Hi, 

There is no problem in striking sec 3.15 from the IG if everybody agrees. We just have to make an agreement about what is the best way of doing things. The IG should reflect that agreement. So I would focus on the agreement instead. Let's work as if section 3.15 did not exist anymore...

I also agree that an SG handling traffic with #ASPs<n might be an intelligent approach. Of course, all kind of alarms should show this situation and the best configuration should be recovered as soon as possible.

Cheers // Javier.

> Sent: miércoles, 26 de febrero de 2003 8:39
> To: TOLGA ASVEREN
> Cc: [email-masked]
> TOLGA,
> TOLGA ASVEREN wrote:                                          
>                        (Wed, 26 Feb 2003 09:18:23)
> > 
> > Samuel,
> > --- "Samuel Dur D. Jeyaseelan" <[email-masked]> wrote:
> > >
> > > Javier,
> > >
> > >
> > >                SG                        +------+
> > > AS1
> > >  normal SS7  +-----+             +-------|      |
> > > -----------> |     |------------/--------| ASP1 |
> > >
> > >  traffic(T)  |     |           /         +------+
> > >     'n' ASPs
> > >              | SGP1|          /          +------+
> > >              |     |---------/-----------| ASP2 |
> > >              +-----+        /     +------|      |
> > >                *           /     /       +------+
> > >                *          /     /        +------+
> > >                **************************| ASP3 |
> > > spare 'k' ASP
> > >                         /     /          +------+
> > >                        /     /              *
> > >              +---- +  /     /               *
> > >              |     |-+     /                *
> > >              |     |      /                 *
> > >              |SGP2 |-----+                  *
> > >              |     |                        *
> > >              +-----+                        *
> > >                *                            *
> > >                *                            *
> > >                ******************************
> > >
> > >
> > > At SGP1 SLS-ASP table
> > > --------------------
> > > SLS             ASP
> > > ---             ---
> > > X               ASP1
> > > Y               ASP2
> > > -               ASP3 (spare ASP)
> > >
> > > AT AS1 SLS-ASP table
> > > -------------------
> > > SLS             ASP        PRIMARY-RT
> > > SECND-RT
> > > ---             ---        ----------
> > > --------
> > > A               ASP1        SGP1               SGP2
> > > B               ASP2        SGP1               SGP2
> > >
> > >
> > > Initially AS1 state at SGP is AS-DOWN.
> > >
> > > SGP requires 'n' ASPs to handle the normal SS7
> > > Traffic 'T', this can be
> > > called as 'best traffic'.AS1 state is changed to
> > > AS-ACTIVE when 'n' ASPs
> > > have become active.
> > >
> > > Suppose ASP1 is failed so 'n' becomes '1'.
> > >
> > > Now the question.
> > >
> > > 1) If AS1 state is changed from ACTIVE to PENDING(as
> > > per IG)
> > >    then no DATA messages will be sent to AS.
> > >
> > >    IMO, we should keep the AS state as ACTIVE.
> > >
> > >    According to q.704 section 3.8.2 we should
> > > reroute the
> > >    traffic to ASP2 provided congestion has not
> > > occured.
> > [TOLGA]IMO Q.704 can't be binding for this decision. The 
> interface between
> > ASP/SGP (especially from SGP to ASP direction) is a MTP3/MTP3-User
> > interface, not a MTP3/MTP3 interface. But I agree that SG 
> behaves like you
> > describe is a clever choice for most of the times. Still my 
> opinion is to
> > leave the decision to SG. SGPs can inform ASPs about this 
> decision with
> > NTFY. This logic can be applied also to other transitions, like the
> > transitions from ACTIVE to PENDING and from PENDING to 
> ACTIVE. Does this
> > count as a solution ýn your opinion?
> 
> The RFC already provides for the above.  It is IG 3.15 that does not.
> Striking IG 3.15 is the best start.
> 
> --brian
> 
> > >
> > >    Just reroute the SLS(X,Y) to available ASP1 , i
> > > beleive this is
> > >    what we follow in legacy SS7 network.
> > >
> > >    When ASP2 transmission buffer reaches congestion
> > > level then
> > >    we can send NTFY to spare 'k' ASP and change the
> > > AS1 state to
> > >    PENDING along with timer running.
> > >
> > >  2)What will happen when the traffic reaches from
> > > 'T' to 'T+1'?
> > >
> > >    At SG 'n' ASPs are not sufficient to handle this
> > > 'worst case'.
> > >    So SG is required to send NTFY to spare 'k' ASP.
> > >    But RFC and IG ignores to handle this case.We
> > > should enhance IG to
> > >    support this case.
> > >
> > >  IG section 3.15 misguides and should be re-writen
> > > to handle the above two
> > >  points.
> >