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

Brian,

For many of the CAMEL/INAP, GSM, and IS41 applications that we deploy,
there is an ongoing dialog (sometimes class 0, sometimes class 1) that
perfectly suits this use of TID routing.  SLS does not solve the problem
of class 0 and there are many applications with ongoing class 0 dialogs.
Also, SLS has other problems (see last paragraph).

I agree that TID does not solve the problem of calls spanning multiple
dialogs, however it's not designed to solve that problem.  It does solve
a set of problems (just like other features in the spec solve other
problems) and therefore it is a valid technology that should be used
where appropriate.

I'm not trying to make the argument that TID routing is the endall
solution for all applications.  I'm only answering Jain Saurabh that
this is a valid technolgy with a practical use that is being deployed in
networks to solve certain problems.  I won't go so far as to judge
whether these applications are trivial/uninteresting.  But I do know
that there is a fairly large market for these applications and this use
of the TID feature in SUA safely satisfies that area.  Obviously, TID
routing will only be used for ASPs that want that type of service.  If
you are running a non-TCAP application or an application with calls
spanning multiple dialogs, it would not send TID in the ASPAC and
another technique must be used.

I don't think SLS is a very good mechanism for routing all calls within
a dialog to the same ASP (at least not in ANSI networks).  While the
initiator of the call will always assign the same SLS value for class 0,
if there is a failure in the network, and the number of STPs that you
are routing through changes, the SLS value at the end point will change
since the STPs are rotating the SLS.  

The problem of call state being preserved is easily solved if you
implement a more redundant system..  When an ASP dies, a notify is sent
out, and another standby ASP can send an ASPAC with the TID value of the
failed ASP thereby solving your stated requirement from RFC3332 below.


Regards,
Lincoln

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

Lincoln,

Did you not read the discussions on the archive?

Haresign Lincoln wrote:                         (Thu, 29 Jun 2006
13:14:44)
> 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.

That would only work for the most trivial of services and is rather
uninteresting.  The purpose was to permit an ASP to maintain a set of
transaction states largely local.  For an _interesting_ service
application, such as GSM MAP, it is also necessary to send all linked
transactions to the same ASP (not just CONTINUE/QWOP), requiring parsing
of the application context or operation and the linked id at the SG.  In
fact better transaction state locality can be acheived by distributing
over the ASPs serving the AS based on Sequence (SLS value) because the
GSM entity will assign the same sequence value to CONTINUE/QWOP (because
they require protocol class 1) as well as linked operations (per GSM MAP
specifications).  Understand?  Another example, a CS/AIN SSP sends
UNIDIRECTIONAL messages to an SCP to indicate call release.  This
UNIDIRECTIONAL, of course, contains no TID, but it does contain a
correlation id (which would have to be parse).  However, CS/AIN, just as
GSM/MAP, sends the UNIDIRECTIONAL message with the same Sequnce Control
(SLS) as the transaction to which it correlates.  Good transaction state
locality, as well as best load balancing, can most easily be provided by
distribution based on SLS.

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

Apples and oranges.  From RFC 3332:

"  For carrier grade networks, the failure or isolation of a particular
"  signalling process should not cause stable calls or transactions to "
be lost.  This implies that signalling processes need, in some cases, "
to share the call/transaction state or be able to pass the call state "
information between each other.  In the case of ASPs performing call "
processing, coordination may also be required with the related Media "
Gateway to transfer the MGC control for a particular trunk "
termination. However, this sharing or communication of "
call/transaction state information is outside the scope of this "
document.

You are not going to get away with requiring the SG to provide complete
locality of state and better locality is afforded in practical
applications by load balancing based on SLS/Sequnce than is afforded by
TID Label and it does not require TCAP decoders, Application Part
contexts and ASE, nor TCAP/TCAP-User state machines.  It is immediately
avaiable in the MTP/SCCP portions of the received message.

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

Linked IDs, and application contexts or operations are not trivial.
Also, you need to consider that TCAP is not the only SCCP user and SCCP
need not be aware of the nature of its users.  If your TID assignment
for distribution goes against SLS assignment rules for, say GSM MAP, one
ASP losing connectivity to an SG will result in failure of all
transactions in the TID range because the SS7 network will always
deliver them to the SG to which the ASP with the TID range has failed.

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

SLS is far better.

--brian

--
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/