Subject: RE: [Sigtran] ASP load sharing..

From: "Schantz, John" <[email-masked]>
Date: Mon, 16 Dec 2002 10:35:37 -0600

Mohan,

	I had identified this problem several months (6 mon. - year,
look at the "ASP ID" thread).  I even proposed that we could use the
optional ASP ID that currently only exists in the ASP UP.  If we added
this optional parameter to the ASP DOWN, then an active ASP could inform
the adjacent SG that a specific ASP ID is down.  This would shorten the
detection time that SCTP has. (a simple solution)

Maybe the group is more open to listening to problems now, I was
basically told it was not a problem back then.

John

-----Original Message-----
From: Mohan Parthasarathy [mailto:[email-masked]] 
Sent: Saturday, December 14, 2002 6:07 PM
To: [email-masked]
Cc: Samuel Dur D. Jeyaseelan; Tolga Asveren; [email-masked]
Subject: RE: [Sigtran] ASP load sharing..

> > 
> > Well said ! Please make no assumptions about how ASPs
> detect failures
> > and how reliable ASPs are.
> > 
> > -mohan
> 
> I'm permitted to make all the assumptions I want.  The RFC

Sure.

> doesn't, so there
> is no problem there.  Besides, I wasn't making assumptions
> about the ASPs
> absolute reliability, I was making statements about the ASPs 
> reliability in
> comparison to the SG.
> 
Ok.

> Considering that SG are SS7 connected, they must meet
> operator reliability
> requirements imposed on SS7 signalling equipment.  This is 
> rather strict in
> public SS7 networks: (e.g. 6 nines instead of just 5 for most STPs).
> 
> One of the major purpose of traffic modes in the UA is to allow lesser

> reliable ASPs to joint together in a system in such a way that the 
> system is more reliable than its components.
> 
> Because in public networks switches and databases only have
> to meet 5 nines
> (not the 6 of STPs), it would be bad engineering and a waste 
> of money to
> engineer the ASP to the level of reliability of the SG/STP.  
> Even if the SG is
> not an STP, but an SEP (5 nines as well), engineering the 
> individual ASPs to 5
> nines and then combining them using UA traffic modes is also a waste.
> 
> So, expecting that engineers will honestly do their job and
> not throw cost
> into the ASP where it is not necessary, it is safe to say 
> that the ASP as a
> component is less reliable than the SG as an SS7 node.
> 
> Can you give an example in a real network where an SG would
> be allowed to not
> meet the reliability requirements of SS7 (and yet be SS7 
> connected) and where
> the ASP has been so over-engineered that it exceeds the SG 
> reliability? ;)
> 
I don't think anyone is going to compete with SS7 reliability :-) But
folks out there are building highly reliable products (PDSN
/GGSN) for the wireless world. I gurantee you that they
are not build out of cheap components. They are designed from scratch
with reliability in mind. Now there is also a need for interacting with
the legacy SS7 stuff. When you are integrating these applications into
these boxes, you still need to provide the same reliability as other
components in the system. So, i am not really comparing with SG. I am
trying to make sure that we can still achieve the same reliability when
integrating these applications. 

-mohan

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 16 Dec 2002 14:45:07 -0700

John,

I didn't disagree with your proposal in June under the thread
"M3UA IG: ASP IDs & a proprosal to solve a network equipement failure
scenario" and from the looks of the thread, those questioning the
proposal didn't think that it addressed network equipment failures,
or ASP failures in that it did not significantly reduce message
delays or loss.

That is probably still the case now (with careful setting of SCTP
protocol parameters, it doesn't significantly reduce message delays
or loss); but I still don't disagree with the procedure as one that
the detecting ASP can optionally invoke if it wants to.  IMO it gives
the ASP one more tool in its toolbox to handle failures in the ASP
pool, which is a good thing.

--brian

Schantz, John wrote:                        (Mon, 16 Dec 2002 10:35:37)