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

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 18 Feb 2003 12:17:54 +0100

Brian, 

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, February 18, 2003 8:32 AM
> 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 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.
> 
> 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.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 18 Feb 2003 04:48:50 -0700

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/