Re: 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/