AS concepts and Relay in SUA and M3UA

Stanislav Ivanovich <[email protected]> Wed, 14 Dec 2005 09:31:52 -0800 (PST)

Newsgroups	gmane.ietf.sigtran
Message-ID	<[email protected]>

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?

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?

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

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 relations, 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".

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 RFC! 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?

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?

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

_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran