RE: AS concepts and Relay in SUA and M3UA

Stanislav,

IPSP is a peer-to-peer model, there is no relaying functionality. It is used
only to enable communication between two AS in IP domain without any
intermediares.

Please see below for more answers.

   Thanks,
   Tolga


-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Stanislav Ivanovich
Sent: Wednesday, December 14, 2005 12:32 PM
To: [email protected]
Subject: [Sigtran] AS concepts and Relay in SUA and M3UA


Hello SIGTRAN experts,

I kindly ask You to help me clarify some important AS and relay concepts of
both M3UA and SUA. I have noticed a question with subject "AS, RK , RC
concepts
in SE model" that Ilie Glib posted on 6th of December and discussion there
raised serious doubts in my understanding of particularly SUA relay.
It looks like that Brian's and Tolga's answers maybe are aligned with
relevant specifications (M3UA and SUA) but I not quite sure since there
might be
inconsistencies in the specifications.
Questions:
1) Both M3UA and SUA specifications in the same sec. 4.3.4.3. "ASP Active
Procedures" say:
"By sending an ASP Active Ack message, the SGP or IPSP is now ready to
receive and send traffic for the related Routing Context(s). The ASP SHOULD
NOT send
Data or SSNM messages for the related Routing Context(s) before receiving an
ASP ! Active Ack message, or it will risk message loss."

I have a configuration of SGP-ASP. SE model used. 2 AS'es registered, namely
AS1:DPC=2-100 and AS2:DPC=2-200. I am considering both M3UA as well as SUA.
ASP
has activated AS1 but not AS2 by sending ASP ACTIVE indicating RC1 only.
Does the reference above mean that after ASP activates AS1 but not AS2 that
it is allowed to send towards SGP but only indicating OPC=2-100 for M3UA or
SPC=2-100 in Source Address for SUA but not indicating OPC=2-200 for M3UA or
SPC=2-200 in Source Address for SUA?
Is the answer the same for M3UA and SUA?
[TOLGA]SE model refers to SE-IPSP. there is only one type of SGP/ASP
relationship. ASP SHOULD send DATA only for an ACTIVE RK, so the answer to
your question is "yes" -for SUA, the situation is a bit different for GT
based RKs-.

2) According to Your answers sent to Ilie in IPSP-IPSP configuration in SE
model one must install the same RK at both processes and the RK specify the
SS7
relation(s). I have this configuration in SE model:

IPSP-A<---------------->IPSP-B
SPC-a1                  SPC-b
SPC-a2
AS1 = SPC-a1 <-> SPC-b
AS2 = SPC-a2 <-> SPC-b
and IPSP-A activates AS1 but keeps AS2 inactive.
Does the SUA/M3UA reference in question 1 mean that IPSP-A is allowed to
send towards SPC-b using OPC=SPC-a1 for M3UA (or SPC=SPC-a1 in Source
Address for
SUA) but is not allowed to send towards SPC-b using OPC=SPC-a2 for M3UA (or
SPC=SPC-a2 in Source Address for SUA)?
Is the answer the same for M3UA and SUA?
[TOLGA]The answer is again "yes".

3) If the answers for questions 1 and 2 is "Yes" that implies that the
concept of Application Servers (which is supported by corresponding ASP
procedures)
used by both M3UA and SUA seems to be extremely unfriendly to the relay
concept as used by traditional SS7 networks.
[TOLGA]Please note that neither SGP/ASP not IPSP/IPSP relationship
corresponds to MTP3/MTP3 relationship of SS7 network. ASP/SGP corresponds to
MTP3/MTP3-User Part realtionship and IPSP/IPSP can be thought as direct
communication between SS7 User parts. Only SG-SG communication mimics
MTP3/MTP3 communication.

Esse! ntially in traditional SS7 networks traffic is managed separately and
independently in both directions while in the AS concept the traffic (at
least in
SE model which is mandatory!) is managed symmetrically. This important
asymmetrical principle of SS7 is reflected on both external as well as API
internal
interfaces.
Thus for example TFP message sent by node A to node B indicating
unavailability of a destination C means that node B cannot reach node C via
node A. However
the opposite direction (if exists at all) is managed separately. The same is
valid for SSP messages of SCCP.
[TOLGA]As said above, only SG-SG communication mimics MTP3/MTP3 relationship
and thus only it functions the way you described.

The same principles are kept for API internal interfaces. Thus when MTP
indicates MTP_PAUSE to a User Part it means that the User Part is not
allowed to send
towards the indicated destination. However this does not mean that the User
Part cannot receive a message from the peer at the indicated concerned
destination. The ! same is valid for SCCP N_PCSTATE and N_STATE indications.
However in the AS concept of xxUA networks one ASP TM message affects the
traffic in both directions (if the answers is "Yes" for the previous
questions).
I noticed in the discussion You have with Ilie Glib that that You claim that
in DE model this management is asymmetrical!
Does that mean that the SUA/M3UA reference in question 1 is not valid for DE
model?
If so, why is that not indicated then?
If You still claim that DE model is asymmetrical unlike SE model Why we do
not have this asymmetrical management for SGP-ASP interface as well since DE
model
is only for IPSP-IPSP interface?
[TOLGA]The asymmetry in DE-IPSP is not a desired behavior but can be
considered more as a shortcoming. Considering that SGP/ASP interface mimics
MTP3/MTP3-User Part interface, I don't see the reason why it should behave
asymmetric.

4) Why do I claim that the AS concept is extremely unfriendly to the Relay
concept? Because in the answer to Ilie Glib as well as in xxUA
specifications You
claim that (at least in the mandatory SE model) that You have to specify SS7
relat! ions, namely OPC and DPC for IPSP-IPSP configurations.
Note that SUA specification differs from M3UA since it explicitly mentions
the concept of Relay function in sec. 1.4.6. "Relay function" (SUA RFC).
There it
says that "The determination of the next hop...may also be based
on...pointcode contained in the called party address".
[TOLGA]SUA does not define relay functionality for IPSP communication.

How could SUA relay be practically achieved if we strictly follow existing
AS concept You want to follow and if You have a network of several dozens of
processes?
In SS7 network it is irrelevant which node sends a message - the only thing
that matters is whether the addressed destination is accessible. However
here in
xxUA networks You have to specify all the OPC-DPC combinations that an AS
supports! For a network of dozen processes it might be 100's of
combinations...
that have to be supported!

5) In one of the answers to Ilie Glib ! You also claimed that there is no
MTP management performed by SUA processes equipped with Relay capability. If
we look
into SUA specification there is no section which describes exchange of DUNA,
DAVA messages between two IPSP processes which are equipped with SUA relay.
However one might consider this as a lack of specification and/or
inconsistency with other parts of the specification! Otherwise how do You
mean it is
possible to support the following SUA configuration:

                     ----------           ---------
            ---------| IPSP-A |-----------| 2-200 |
           /         ----------\         /---------
          /                     \       /  IPSP-2
---------/                       \     /
| 2-100 |                         -----
---------\                       /     \
 IPSP-1   \                     /       \
           \         ----------/         \---------
            ---------| IPSP-B |-----------| 2-300 |
                     ----------           ---------
                                             IPSP-3

SCCP application at IPSP-1 place communicates with SCCP applications at
IPSP-2 and IPSP-3 places by using their SPC addresses. The communication
goes over
IPSP SUA relay processes IPSP-A and IPSP-B which act as proxies between the
processes, namely relay processes represent IPSP-2 and IPSP-3 to IPSP-1 and
IPSP-1 to IPSP-2 and IPSP-3. We intend to use SE model.
We define:
AS = (2-100 <-> 2-200) and (2-100 <-> 2-300)
at IPSP-1, IPSP-A and IPSP-B places.

AS2 = 2-100 <-> 2-200
at IPSP-2, IPSP-A and IPSP-B places.

AS3 = 2-100 <-> 2-300
at IPSP-3, IPSP-A and IPSP-B places.

If the SCTP association between processes IPSP-B and IPSP-3 fails how can
the SUA relay process IPSP-B indicate to IPSP-1 process its incapability to
support
relation 2-100 <-> 2-300 while the relation 2-100 <-> 2-200 is still
available? One would normally expect that IPSP-B sends DUNA message to
IPSP-1 indicating
inaccessibility of 2-300.
However this procedures are not described in the SUA R! FC! And You claim
that there are no DUNA, DAVA... messages to perform MTP management on
IPSP-IPSP
interface even if You have SUA relay!
Note that if these SCCP applications reside in classical SS7 network and if
IPSP-A and IPSP-B nodes are MTP STP nodes (MTP relay) then SCCP application
in
node 1 would be isolated from this failure by MTP layer which would perform
the re-configuration.
In another words it is true that SCCP application in node 1 would not be
informed by N-PCSTATE primitive of SCCP but the failure would be catered by
the
lower (MTP) layer.
The question is, shouldn't SUA then isolate its users from this failure by
performing the same job as MTP does in this case? In another words shouldn't
SUA
relay (and SUA gateway) include MTP STP functionality? That would imply that
You need  exchange of SSNM messages between two IPSP processes what You
claim is
not allowed!?!
Otherwise what should IPSP-B node do in this case (if not to send DUNA
message)?
Actually, the ultimate question is -> how should SUA relay work after all?
(especially considering AS concept, ASP/IPSP traffic management procedures
in the
multiple AS'es per signalling process environemet)

6) Is there at least "hidden" - if not explicit - M3UA relay in M3UA
specifications? Is it allowed to send SSNM messages between 2 IPSP processes
for M3UA?
[TOLGA]No, although this is not 100% clear in the specifications -yet-. Only
SCON is used to convey congestion information and hopefully we can replace
it soon with an ASPTM.

7) Does the reference to SUA/M3UA specification in question 1 means that if
an SUA AS is specified as Destination_Address_GT=xyz that if the AS is not
active
the process is not allowed to send any message with Source_Address_GT=xyz?
[TOLGA]As far as I know, for GT based RKs there is no such restriction.

I would very much appreciate that Your answers either contain references to
the existing specifications, or if these are to be updated then some
indication
that the issues (! if any) would be addressed in the next version of the
specification(s) (e.g. "SUA Implementor's guide").

Thank You very much in advance for Your answers!

best regards/ Stanislav Ivanovich



Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping