RE: [Sigtran] Multiple SUA SGs, sending for SSP from SGs

["Tolga Asveren" <[e-mail]>]

Stanislav,


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of
Stanislav Ivanovich
Sent: Friday, January 13, 2006 9:48 PM
To: SIGTRAN
Subject: Re: [Sigtran] Multiple SUA SGs, sending for SSP from SGs


Dear Brian and Tolga,

First, thank you Tolga and Brian, indeed very much for your great
contribution and patience both of you show to all of us SIGTRAN implementors
every single day by answering long questions!

Please, I kindly ask you to have just a little bit more patience with this
(in my view) very essential issue. As we have seen here whatever question
one arise (in this case multiple SG'es or something else) he/she will finish
at the core of the issue which I am to be honest very afraid of.


Brian,

I really see no problems in understanding AS concepts when they apply on
interface between MTP3/SCCP and their user-functions or in-between two
user-functions whatever you call the hosting processes. However when one
applies this concept in between two MTP3/SCCP instances I have tremendous
conceptual problems.

I understand your proposal Brian and this seems reasonable -> if one does
not want/like the AS concept in between two MTP3/SCCP instances then he/she
does not need to use it (to be honest I thought it was mandatory since RC
was mandatory parameter is DATA messages of SUA but now I see that this is
not the case). However if one vendor supports this (because he understands
this) and my company does not support this (because I do not understand it)
this brings my company in serious disadvantage! Therefore regardless of
implementation of a particular feature the xxUA protocols offer I first need
to fully understand all the capabilities/possibilities the specifications
give me.
[TOLGA]Actually using one RK on an association does not change anything much
in terms of using "AS concept". It still is there, just implicitly
identified.

My point is that in my current understanding AS concept in between two
MTP3/SCCP instances brings me just restrictions (i.e. some configurations
are not possible), while OTOH I get nothing "in-return"  (e.g. better
redundancy... etc). In my view SGP-SGP brings you the same redundancy as
ASP-SGP and IPSP-IPSP protocols while it does not impose any kind of
restrictions. Which restrictions?

Here are just few of them:

1) if AS is to be used in between 2 MTP3/SCCP instances then it implies that
AS represents an SS7 destination. However in MTP3/SCCP networks relay can be
easily built because when one sends traffic it is irrelevant what is the
state of the sending entity. What only matters is the accessibility state of
remote destination.
For example if I have SGP connected to ASP equipped with relay which serves
local user for 2-100 and supports relay for 2-200 then according to xxUA
specifications ASP must not send (!) traffic until it is not prepared to
receive any. So ASP has to activate its (local) receiver for 2-100 just to
make 2-200 possible to send traffic over it to SGP!?! Why this?
This! would imply that ASP has to register 2-200 at SGP also what is very
different from SCCP/MTP3 relay. In MTP3/SCCP networks one can have a sender
sending over relay and receiving traffic over another independent relay.

My comment is -> This has serious consequence on building of relay networks
based on these AS principles. It is obvious why in both M3UA and SUA
specifications it is explicitly said ASP is not allowed to send (!) until it
is activated itself within an AS at SGP (thus be able to receive) -> this is
how User Parts (or SCCP users) work: if they are not connected to MTP3/SCCP
layers then they will not be able to either send or receive traffic. However
if we do not understand AS'es as MTP3/SCCP user functions but as SS7
addresses in between two MTP3/SCCP instances then this becomes serious
restriction.
Note that removing restriction for ASP/IPSP to send (!) traffic regardless
of its activation within an AS is not "administrative" but has serious
technical consequence -> moving of SSNM messages from SGP to ASP from ACTIVE
to DOWN state...
[TOLGA]It is clear that ASP/SGP interface mimics MTP3/MTP-User and
SCCP/SCCP-User interfaces for M3UA and SUA respectively. Hence, the
corresponding MTP3, SCCP logic resides in SG. This is a nice model if SG
does not act as STP.If SG acts as STP, MTP3 logic for AS is hosted at SG. As
it stands right now, there is no relaying based on ASP/SGP model in
M3UA -what "SUA relay" really means is a question mark to me, I personally
think it probably is something similar to SG-SG for SUA based on PC+
SSN routing. IPSP for M3UA does not support realying and I think it doesn't
for SUA as well.
If one looks to the relationship between two MTP3-instances, one sees that
it is a peer-to-peer relationship between two network layer entities. Such a
relationship supports relaying.
The relationship between  MTP3/MTP3-User is a client/server relationship and
does not support relaying.
The relationship between two AS is a special one, is peer-to-peer but on
application level and thus it is not logical to think of relaying there on
signaling transport level.

2) In traditional MTP/SCCP networks one can have destination SPC1 reachable
over two STP functions STP1 and STP2 while SPC2 reachable over only STP1 for
example.
However by having the AS concept one is not allowed to have at SPCx place
(for example an IPSP) an SS7 address in two different AS'es. So AS1 cannot
be (SPC1, SPC2) and STP1 is a process supporting AS1 while AS2 is (SPC1) and
STP2 is supporting AS2. Because of resolution problems at SPCx place which
must have AS configuration in this way: AS1 (SPC1) supported by STP1 and
STP2 and AS2 (SPC2) supported by STP1 one must introduce 2 AS'es at STP1
place!
This kind of influence of one node on the configuration of other one you
cannot find in traditional SS7 networks! Another practical problem!
[TOLGA]My first question to you is, why do you think that relaying using AS
constructs is supported? It isn't -I excluse SUA realy here because I don't
know what it officially means-.

!
3) Please Brian, I kindly ask you to make your opinion about this (I would
very much appreciate opinions of other SUA RFC co-authors as well!) -> if we
allow that ASP/IPSP hosts MTP3/SCCP layers then this is not only against
basic definition in the SUA paper itself:

e.g. SUA RFC section 1.2.2. "Terminology":
"IP Server Process (IPSP) - A process instance of an IP-based application.
An IPSP is essentially the same as an ASP, except that it uses SUA in a
peer-to-peer fashion."

but even more -> this is very serious conceptual problem!

Why do we define several process types and 2 different protocols if there is
no difference between the processes?
By reading all the threads last weeks I see that even ASP can send SSNM
messages towards SGP, IPSP can send and receive SSNM so actually even the
difference between the protocols themselves disappears!
[TOLGA]This is not true, ASP can send only SCON -which IMO is a bug in
M3UA/SUA, we should have had ASPCONG from very early on, Brian started to
work on a draft for this-. The same holds true between IPSPs.


This is very serious conceptual problem for which I haven't still received
any convincing answer -> the only answers I received are these:
----------------------------------------
[John Loughney]
"Process-types, in my view, are illustrative text, to give an implementor an
idea of what we are talking about - however, they are not meant that each
capability MUST be implemented as a separate process."
----------------------------------------
[John Loughney]
"The notion of a process, IMO, is an implementation issue - different OSes
may behave different."
----------------------------------------
see thread "[Sigtran] AS concepts and Relay in SUA and M3UA"

I am really very sorry but this does not sound very convincing, does it?


4) If the essence of the AS concept is a redundancy ! concept (AS is served
by several signaling processes) then there is no redundancy scheme which
SGP-SGP concept does not provide and which could be provided by existing
protocols (ASP-SGP and IPSP-IPSP). However advantage if SGP-SGP model is
that it does not suffer from the restrictions/problems described in point
1-3 above.
However SGP-SGP concept provides us with the resolution of all the problems
described in points 1-3 above and at the same time it preserves the existing
protocols and keeps the signaling process definition clear and consistent!


Tolga,
Thank you for your comments!

I do not only understand this:

[Tolga Asveren]
"AFAICS, the main advantage of ASP/SGP model is to allow routing on AS
level, i.e. in sub-PC granularity."

In my view this is not effectively possible. Yes, one can have AS co!
nfigured as User Part of SCCP SSN (i.e. granularity below SPC). However, in
my view, this does not imply that relay based on this is effectively
possible!

This is for the following reasons:

1) How would STP based on finer granularity support this kind of management?
When a process receives DUPU indicating UPU or SSP then it will not try to
divert traffic to another "STP" since it assumes that the user function is
dead rather then STP connection to it. Especially if we are to relay that
UPU/SSP message into SS7 network...
[TOLGA]I meant it in the other direction, i.e. for messages from SG to ASPs.
The practical value of this depends also on the internal communication
mechanisms of ASPs but still could be useful is SLS type of routing is not
good enough, e.g. one has two applications on different SSN and prefers that
ASP1 receives traffic for app1 and ASP2 for app2 unless one of them fails.
This of course is only for ASP/SGP communication.

2) Different types of traffic granularity require support for different
types of Traffic Management in order to support relay based on different
granularities.
ANSI MTP is a good example -> there you can find the concept of Cluster
Destinations. However the essence of this concept is that it is unique
granularity across all the STP nodes&nb! sp;which is not the subject of
"bilateral" agreement between two adjacent STP nodes what we have with IPSP
processes equipped with relay capability.
In other words in ANSI MTP networks all the STP across the network that is
to use Cluster concept use the same (!) traffic granularity which is
supported by the same Traffic Management which is not subject to agreement
between two STP nodes but spans across the whole network.
In xxUA networks we have management by SSNM and AS is the agreement between
two adjacent nodes... All in all - in my opinion not very efficient...
[TOLGA]IPSP does not support relaying and if you look to the definition of
it it simply doesn't  make sense forcing it to support relaying. It is a
direct relationship between two applications and any necessary relaying
should happen on application layer, not on signaling transport.
Overall, I think I agree with you.



Thank you both Brian and Tolga once again for your great support to SIGTRAN
community as well as your patience!

with best regards/ Stanislav Ivanovich



"Brian F. G. Bidulock" <[e-mail]> wrote:
Stanislav,

Neither the ASP-SGP nor IPSP-IPSP models require you to use AS or RC.
Define 1 AS per ASP only and give it RC value 0. Make that AS an entire
point code (or network appearance for that matter). Then this RK:AS:RC
3-tuple that bothers you so much falls away.

--brian

Stanislav Ivanovich wrote: (Fri, 13 Jan 2006 12:19:29)
>
> Hello,
>
>
>
> In addition to the last mail:
>
>
>
> The original idea was to have one user function at ASP connected to 2
> SGW (thus two independent SCCP/MTP layers). So in order to solve this
> we said -> we need an (i.e. 1) MTP/SCCP layer at ASP place which is to
> communicate with independent MTP/SCCP layers at SGW'es side.
>
>
>
> However here you again have one user function connected to one
> MTP/SCCP layer. This ! is exactly what the Tolga's SGP-SGP solution
> covers. The only difference is that ASP-SGP and IPSP-IPSP protocols do
> mandate use of AS concepts with all the restrictions which imply from
> these protocols... which we do not have in SGP-SGP protocol.
>
>
>
> So again we have very fundamental question -> what does AS/RC concept
> provide us with on the interface between two MTP/SCCP relay equipped
> processes?
>
>
>
> It brings us just restrictions and problems nothing else!
>
>
>
> / stanislav
>


--
Brian F. G. Bidulock
[e-mail]
http://www.openss7.org/





Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays,
whatever.



_______________________________________________
Sigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sigtran