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

Brian,

One way to implement this for TID so it works (sort of) is as follows.

The ASP (within the AS) assigns it's own unique value.  For example,
let's say it has a bit mask of 8 bits (allowing for up to 2**8 unique
ASPs).  And it specifies a range in the part of the TID that is built by
the ASP (local TID).  

When a BEGIN arrives at the SG, it can be routed to any ASP (perhaps in
a round robin fashion).  For a CONTINUE or END, the TID would be parsed
and correctly routed to the ASP that is handling that call.

Downsides:

1) If an ASP dies (or becomes inaccessible), then yes all calls in
progress for that ASP are lost.  Although if I'm an endpoint and I
crash, same thing.  In the case of SG-ASP, loss of an ASP only results
in loss of a subset of calls.

2) The SG needs to parse part of the TCAP message (TID and message
type).  This isn't really a TCAP stack, only a little decoding in the
inbound direction.

I think this provides a valuable feature in SUA for message distribution
within an AS.

Regards,
Lincoln


-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Thursday, June 29, 2006 1:01 PM
To: Haresign Lincoln
Cc: Saurabh Jain; [email protected]
Subject: Re: [Sigtran] SUA: Message distribution among Load Shared ASPs
(IPSPcase)

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/