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

Brian,

I would be happy to review your documents if/when they are distributed
throught the IETF as drafts (I think I said this about six months or so
ago).  In the interim, since TID routing is the only existing approved
solution, there's certainly no reason why people can't use/adopt it.  

There are a couple reason that immediately come to mind why SLS is not a
good mechanism.  The first is fact that SLS can change in an ANSI
network.  For example, if point code A is connected to point code B via
LINKSET F (direct F linkset) as well as LINKSET A1 and A2 (combined
linkset to a pair of STPs).  

Initially the call is going through LINKSET F (with no SLS rotation) and
when LS F fails, it goes through the STPs and now the SLS is rotated.
There are no TFPs, no STP failures, just a backhoe.

The second reason SLS is not good is that you are limited to either 16
or 32 ASPs (8 in some japanese networks).

Regards,
Lincoln



-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email protected]] 
Sent: Thursday, June 29, 2006 2:53 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 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.t
xt

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/