Re: RE: draft-bidulock-sigtran-tua-04.txt

Tolga,

Tolga Asveren wrote:                                                                 (Fri, 21 Oct 2005 17:29:29)
> Brian,
> > Please point to the place in the draft where you believe
> > these overwhelming defficiencies exist that preclude TUA
> > from being a useful protocol.
> [TOLGA]I did not say that but it is true that personally I am not sure -let
> me clarify that this is a non-rhetorical "not sure"- whether a TCAP-User
> Interface based UA protocol is necessary -regardless whether it is the draft
> you are mentioning or something else-.
> 
> Regarding the concept -below I use TUA to refer to a TCAP-User Interface
> based UA protocol, not to the specific protocol defined in the draft-:
> 
> 1- There is nothing preventing people to be creative in terms of RK types
> supported for SUA -even for M3UA-. If application specific parameters are
> going to be used for message distribution purposes at SG, SG will perform
> deep packet inspection. This deep packet inspection is necessary also for
> TUA if one wants to use application specific parameters, e.g. IMSI. Are we
> going then to have a UA protocol for each application type to prevent deep
> packet inspection? I consider support for different RK types as an
> implementation dependent feature, which is also a differentiator for a SG.
> Just because it is related with that, probably most people will remember how
> CIC based RKs were removed from M3UA specification -I don't have problem
> with that, still one can have any type of RK as long as it is statically
> configured-. I know commercial M3UA SGs, which support CIC based RKs,
> without requiring any modifications to M3UA and with no specific behavior
> expected from the peer, i.e. totally based on local procedures. I believe
> the issue of routing messages on SUA SG based on non-SCCP constructs is
> similar to that, anything is allowable as long as it is relying on local
> procedures.
> 
> 2- How scalable is TUA architecture? Can one have multiple SGs -probably
> not-? Will it have something similar to relaying -probably not-? Will SG
> become a bottleneck easily -probable-. Will TUA have mechanisms to support
> geographical distribution of traffic on SG side-probably not-? I believe
> that TCAP itself is not a transport protocol may create problems related
> with those issues.
> 
> 3- What will TUA enable us, which is not possible with SUA? Will the net
> effect be trading deep packet inspection for TIDs with TCAP processing on
> SUA SG?

I can't speak to your hypothetical protocol, because it is not defined, but
as regards "what can TUA do that SUA can't?" I pose the question "what can
SUA do that M3UA can't", or "what can M3UA do that M2UA can't", or "what can
M2UA do that M2PA can't."

> 
> Regarding the TUA in the draft -below I use TUA to refer to the TUA as
> defined by the draft-:
> 1- It could be an idea to cut protocol stack between TCAP component and
> transaction sublayers.Why should one care about component layer processing
> if the goal is just to implement transaction processing for TID based RKs? I
> know that this sounds strange but OTOH there may be advantages as well:

The draft provides transport of both (or either) the TR/TR-User interface and
the TC/TC-User interface.  Use whichever you want.  It is probably not a good
idea to prohibit others from using the TC interface even if you believe that
the TR interface meets all needs.

If you read the draft, you will see that there are two groups of messages,
Dialogue Handling (DH) messages that correspond to the TR/TR-User interface
and Component Handling (CH) messages that correspond to the TC/TC-User interface.

If you read Q.771, you will see that the TC primitives are simply a superset of
the TR primitives.

For example, the TQRY message described in section 3.3.3 can have Components
included in the message and Note 2: says: "Any components SHOULD be included in
the TQRY messages but MAY be formatted in separate Component Handling (CH)
messages."

Have you read the draft?

> a)Less processing on SG

Having an SS7 stack, the SG is usually more capable at performing protocol
processing than the ASP.  To do the least processing at the SG, use M2UA.
A benefit of TUA is one can do the least amount of SS7 specific processing
at the ASP (and therefore the ASP need not worry about SS7 localizations, such
as protocol variant).

> b)Simplifies messaging between ASP and SGP

Both options exist in the draft.  You will also find both methodologies present
in Q.771 and in the Java JTCAP specification.

> c)May help to prevent/minimize possible race conditions happening because of
> separation of Component Layer state machine and TCAP-User on different
> entities(Actually it may cause race conditions between component and
> transaction sublayers).

An yet you think that SUA is capable of this?

The need for component handling arrises when, as can often occur in today's
TCAP protocols, the components are too large to fit in a single TCAP package
(or a single SCCP message) and, therefore, segmentation must be performed by
speparating component into multiple TCAP packages.

TCAP utilizes a timeout that defines the amount of time that the TC provider
will wait for additional components before an invocation is cancelled.  This
parameter is included in the CINV message and is described in section 3.11.2.8
of the draft.

If you understand the component handling state machine, component handling is
merely a set of sequential operations used to build an invocation or response
component by component instead of all at once.  There are no races in the
procedure.

> Well, the disadvantage is of course that one needs to split TCAP stack in
> two pieces, maybe a problem for stacks which don't have a properly designed
> interface between Component/Transaction sublayers.

Does matter: the way the draft is written component handling can be used or not.
There are situations where it is necessary.

I don't see any difference between an improperly designed SCCP-User and an
improperly defined TC-User.  An improperly designed user will always encounter
problems.

--brian

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