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

Lincoln,

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

You miss the current fundamental design principle for the SG/ASP relation
in load-share mode: each ASP must be prepared to receive any message as
the load sharing algorithm is completely at the discretion of the SG.  TID
label passes decision of the load sharing algorithm to the ASP from the SG.

There is a draft for doing that properly that includes TID and DRN values
for SUA as well as SLS values for M3UA.  The major difference is it includes
proceedures for registration and notification.  Then, if an ASP serving a
load selection fails within an AS, the SG pends on the load selection and
other ASPs serving the AS are notified as to the failed load selection range
so that they can agree which will pick up the load.

See
http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.txt

This draft was resubmitted on Monday, but missed the cutoff so it will not
hit the IETF servers until some time after the meeting on or about July 10th.

See also
http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadgrp-04.txt
for a way to both stripe and mirror.

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

You should know that not even the SS7 network can handle dual simultanous
associated STP failures:  the result would be TFP rather than routing
through a different number of STPs.

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

The state machine at the SG does not pend on TID range, only on the entire
routing key.  It has no choice but to send those messages immediately to
some other ASP.

Again, see http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-loadsel-04.txt

These drafts provide a complete mechanism, state transitions, registration,
error and notification procedures and represent a usable mechanism.  The TID
label in the SUA RFC was pushed in at the last moment and is half-baked to
say the least.  Along with then procedres are mechanisms for avoiding message
missordering and loss in
http://www.openss7.org/internet-drafts/draft-bidulock-sigtran-corid-06.txt

These drafts have been around for 4 years.  Perhaps you should take a look
at them sometime.

Without the complete set of procedures, someone might thing that they can get
away without sharing state between APS at all.  Without implementing the
LOADSEL draft, if your ASP design has much difficulty moving state between
ASPs, I suggest you move distribute messages between ASPs using your own TCAP
decoders and message distributors, that can more easily use things like TID
and linked ids and properly handle P-Aborts for malformed messages.  If a
message arrives at the wrong ASP, instead of moving the state to recieving
ASP, transfer the message to the ASP that owns the state.  It is something
that you will need to do anyway as the group concensus was that the TID label
procedure must be OPTIONAL.

--brian

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