Re: SUA: Message distribution among Load Shared ASPs (IPSPcase)

"Brian F. G. Bidulock" <[email protected]>
Newsgroups gmane.ietf.sigtran
Organization http://www.openss7.org/
Message-ID <[email protected]>
Lincoln,

Haresign Lincoln wrote:                   (Thu, 29 Jun 2006 09:55:47)
> 
> Perhaps I'm missing something.  Why would it not work in the multiple SG
> scenario?  I'm assuming here that the ASP would use the same TID
> parameter in the ASPAC message going towards both SGs.

TID would require implementnation of both TCAP message decoding and
transaction state machines at the STP/SG.  This is not appropriate.  Nor
are STPs normally equipped with general purpose TCAP protocol stacks.
TUA provides this capablity at the SG.  There is much discussion on this
topic on the archives dating all the way back to about 2001.

(Also, consider the SUA equivalent problem of your M3UA problem with
SI-based routing: one ASP supporting a TID range looses communication
with one STP/SG only.  Are all of the messages lost?  What can the SG
do?  It cannot send P-Abort because there is no message for a failed TID
range.  Shoud it send the message to the other STP?  What if the ASP for
a TID range is isolated from both?  With the associated STP send the
message back forming a loop?  In the M3UA case the STP can track UPU,
but there is no equivalent for a TID range.)

DRN is very broken for STP/SG.  It currently requires the coupling of
connection sections at the SG, an unacceptable restriction (SS7 does not
require coupling of connection sections at the STP and it is in fact not
normally done).  The counter-proposal before WGLC on SUA was a
registration mechanism whereby connection references could be registered
by the ASP on a connection by connection basis with both SG/STP so that
coupling of connection sections at the STP would not be the only way to
support protocol classes 2 and 3.  Without this support, SUA is
incapable of providing seamless or transparent interworking for protocol
classes 2 and 3.  Again, there is also much discussion on this topic
dating back to 2001.

(Note that coupling is also unnecessarily required at every IPSP relay
point.)

Both are quite broken.  DRN can be fixed.  TID cannot.  Labels should be
done away (or at least made strictly OPTIONAL) for the all scenarios and
support for error situations need to be added to make them even workable
as an option.  See the threads.

--brian

-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.