Stanislav,


-----Original Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@yahoo.com]
Sent: Wednesday, December 14, 2005 3:22 PM
To: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

First, thank You very much for Your prompt answer.

I have a strong feeling that the Relay has been added "ad hock" to SUA!

The fact is that SUA made more or less copy/paste from the M3UA
specification of the critical AS/ASP/IPSP procedures which seem to be
originally designed for direct-to-direct relations, but these have not been
modified to support the relay concept in SUA (efficiently).

In traditional SS7 networks which do support relay efficiently you do not
have to specify originating and destination addresses but only the
destination address when specifying Route Sets. However this is
inefficiently if you want to base your relay (in SUA) on the AS concept as
currently defined.

For IPSP-IPSP configuration either you say:

1) It is one the same RK installed at two IPSP places (i.e. one AS) (as you
claimed when you had discussions with Ilie Glib) or
[TOLGA]Yes, just to be more clear, there are altogether 2 AS and 1 RK, one
AS on each IPSP side, but on each end 1:1 mapping between RK and AS holds.

2) or these are 2 AS'es but these have to be bound since in SE model
activation of one AS implicitly assumes activation of another AS

In both cases only messages belonging to the specified SS7 relation(s) are
allowed between the processes.

For example IPSP-1 owns 2-100 and IPSP-2 owns 2-200.

In the first case you say it is 1 AS defined as
- "DPC=2-100;OPC=2-200" at IPSP-1 place and
- "DPC=2-200;OPC=2-100" at IPSP-2 place

(in this case you have 1 AS at each IPSP place)
[TOLGA]This is SE-IPSP.

or in the second case you specify:
- "local AS1" as "DPC=2-100" and "remote AS2" as "DPC=2-200" at IPSP-1 place
and
-  "local AS1" as "DPC=2-200" and "remote AS2" as "DPC=2-100" at IPSP-2
place
[TOLGA]This is DE-IPSP.

(in this case you have 2 independent AS'es - local and remote one - at each
of the places which are bound)

However according to your answers below only messages belonging to
2-100<->2-200 relation (in both directions) are allowed.
[TOLGA]This is how IPSP is supposed to work by definition. There are two
entities which communicate with each other directly. If they are identified
by PC, it is natural that all traffic flowing between those entities will
originate and end at those PCs.

Could you, please, confirm this for SUA once again?

However this is very unfriendly for the Relay concept, since I have to (one
way or another) specify both OPC and DPC!
[TOLGA]AS I said before, IPSP is never thought to support relay concept. I
personally am not aware of any existing plans to have relaying functionality
for SUA IPSP.

Even more you claim that there is no IPSP-IPSP relay in SUA. Strictly
speaking there is no section in the SUA specification which is to define the
concept of IPSP-IPSP relay (or is there any?). However one might say that
this is lack of specification in the SUA paper.
Are you saying that the configuration I sketched below in point 5 is illegal
for SUA?
[TOLGA]As far as I know it is illegal.

Why the relay in SUA is not explained in the RFC? Are there any plans to
explain it in the "SUA Implementor's guide"? How is SUA Relay supposed to
work in the mulitple AS/RC per proecess environments?
[TOLGA]I don't know what is the current plan in terms of detailing SUA
Relaying Procedures.

Does SUA gateway includes MTP STP functionality? (In anothewr words can SUA
gateway relay SCCP messages based on SPC only rather than GT? Or send TFP
messages into SS7 network?) RTFC says just GT but my colleagues consider it
lack of specification, isn't so?
[TOLGA]You should be able to relay based on PC as well. Actually this is
mentioned in RFC 3868 "1.4.6 Relay function".

thnak you once again for your cooperation!

/stanislav



Tolga Asveren <asveren@ulticom.com> wrote:
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: sigtran-bounces@ietf.org [mailto:sigtran-bounces@ietf.org]On Behalf Of
Stanislav Ivanovich
Sent: Wednesday, December 14, 2005 12:32 PM
To: sigtran@ietf.org
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



_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran





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



_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran