AS concepts and Relay in SUA and M3UA

[Stanislav Ivanovich]

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.

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.

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

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?

 

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
Sigtran@...
https://www1.ietf.org/mailman/listinfo/sigtran

[Tolga Asveren]

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@... [mailto:sigtran-bounces@...]On Behalf Of
Stanislav Ivanovich
Sent: Wednesday, December 14, 2005 12:32 PM
To: sigtran@...
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@...
https://www1.ietf.org/mailman/listinfo/sigtran

[Tolga Asveren]

Brian,

There is relay functionality defined for SUA SGP/ASP, but I don't think
there has been some official work done yet in terms of SUA IPSP relay
functionality -I may be wrong though-. As far as I can see, SUA-IPSP
directly mimics M3UA-IPSP, that was the rationale behind my statement.

    Tolga

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock@...]
> Sent: Wednesday, December 14, 2005 1:58 PM
> To: Tolga Asveren
> Cc: sigtran@...
> Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
>
>
> Tolga,
>
> > [TOLGA]SUA does not define relay functionality for IPSP communication.
>
> Well... I believe it does.  Only M3UA restricted away relay functionality.
>
> --brian
>
> --
> Brian F. G. Bidulock
> bidulock@...
> http://www.openss7.org/
>

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

[Brian F. G. Bidulock]

Tolga,

> [TOLGA]SUA does not define relay functionality for IPSP communication.

Well... I believe it does.  Only M3UA restricted away relay functionality.

--brian

--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/

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

[Tolga Asveren]

Stanislav,


-----Original Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
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@...> 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@... [mailto:sigtran-bounces@...]On Behalf Of
Stanislav Ivanovich
Sent: Wednesday, December 14, 2005 12:32 PM
To: sigtran@...
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@...
https://www1.ietf.org/mailman/listinfo/sigtran





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



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

[Stanislav Ivanovich]

Hello SIGTRAN community,

 

I have had a discussion with Tolga Asveren about fundamental concepts around SUA Relay. I have noticed that most of my communication with him was held outside the SIGTRAN community mailing list (I addressed him directly) therefore I correct this now. You can look for the first part of the discussion at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05525.html and the rest is below.

 

My point is that SUA Relay hardly fits into the AS/RC concept which is originally designed for SGP-ASP and IPSP-IPSP (direct) communication. The point is that if the applications are in IP network there is no relay between them on the level of SUA protocol.

 

However Tolga convinced me that actually SUA Relay means:

 

ASP1-SGP-ASP2

 

I do not have conceptual problems with this and I accept this! Note also that this means that one can build SUA relay between two IP resident applications only in one relay stage, since SGP-SGP is not part of SUA specification!

 

However I have tremendous problems with something like this:

 

IPSP1-IPSP_R1-IPSP_R2-IPSP_R3-........-IPSP2

 

where IPSP_Rx stands for IPSP process equipped with relay capability.

 

The problems get even bigger if one wants to build the whole (fully or partly) meshed network of IPSP_Rx processes. This is impossible to incorporate into the AS/RC concept which is normally used on the IPSP-IPSP interface.

 

I would like to hear what other members of the SIGTRAN community think about this since by looking into the SIGTRAN mail archive I see that many peopl! e think that SUA might relay with many IPSP processes interconnected what seems to me hardly compatible with fundamental AS/RC concepts.

 

Please look into the mail below for discussion.

 

 

I would also like to draw attention to the unofficial draft being written by Tolga for SG-SG communication for M3UA (see mail below for address where you can fetch it).

 

I think that this concept is especially usefully for SUA and should be extended to SUA as well. For example if one wants to have GT translation distributed in space (i.e. to build network of relay nodes that are to perform GT translation) then we need SGP-SGP communication.

 

I also think that we should have AS/RC concepts kept away from the SGP-SGP interface.

 

Currently (according to Tolga's view, and my also) only ASP1-SGP-AS2 relay is possible in SUA with jus! t one relay stage.

 

I kindly ask SIGTRAN comunity to give us its opinion.

 

best regards/ Stanislav Ivanovich

 

Tolga Asveren <asveren@...> wrote:

Stanislav,

SG-SG work is going on, initially for M3UA but it hopefully will be extended
for SUA as well. Currently it is not an official WG-item, if you think it is
some useful concept, you can express yur opinion in the SIGTRAN WG mailing
list. For a draft to become WG-item, there should be enough interested
parties in it and right now we probably are short of it.

The link for M3UA SG-SG draft is:
http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uasgsg-00.txt

Tolga
-----Original Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Se! nt: Thursday, December 15, 2005 1:43 PM
To: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

Now I see Your point and I must admit that I fully agree with You!

I have a proposal how to define SUA relay and at the same time be fully
compatible with the AS/RC concepts which are originally tailored for SGP-ASP
and IPSP-IPSP communication without any relay (except in SGP between SS7 and
IP).

My essential point here is that if one wants to incorporate a relay process
in between SGP and ASP or two IPSP'es he/she will finish in tremendous
conceptual problems especially in the environment of multiple processes and
multiple AS'es per signalling process environments.

I am not saying that it is impossible to define SRP1 (SUA Relay Process in
between SGP-ASP) and SRP2 (SUA Relay Process in between IPSP-IPSP) which are
both to use AS concepts. For example SRP1 would mimic an SGP (or maybe even
several SGP's) when communicating with an ASP and ASP (or maybe even several
APS'es) when communicating with an SGP.

But this seems to be feasible only for very simple configurations without
many AS'es and processes involved.

Even more if we allow a relay process which will send SSNM messages to an
IPSP this could be considered as a violation of fundamanetal AS principles
since exchange of this calss of messages (expcet of course SCON) is not
allowed there.

One might then say: "OK if a relay proces is supposed to send SSNM messages
then instaed of IPSP we have ASP".

We need just one additional step to find the soltuinon -> the SCCP alike
relay (GT or maybe even SPC based) is essentialy possible as you once said
between SGP processes.

Thus we finish in this configuration:

ASP1---SGP1--------SGP2---ASP2

In this case we equip (define) the SGP'es with procedures to relay from IP
to IP network! (i.e. access to SS7 network is not always necessary) and
that's it!

However it is essentially important to note that in this case AS concpet
finishes/terminates on the SGP'es. In another words we have AS1 served by
ASP1 and "terminated" at SGP1 and AS2 served by ASP2 and "terminated" by
SGP2. But SGP'es do not use AS concept for SGP-SGP communication but instead
use SCTP associations like SCCP uses MTP links (or Route Sets.... whatever).

In this way the construction is closed and the relay perfectly fits into SUA
network and is comaptible with AS concepts which are kept away from the
SGP-SGP interfaces. And the original prinicples of AS are kept intact and
consistent!

What do You think?

best regards/ Stanislav


Tolga Asveren wrote:
Stanislav,

a)Both for SUA or M3UA, IPSPs can't relay.
b) Relaying in SUA is *NOT* IPSP communication and its details are not well
defined, but I don't se! e why it should effect ones understanding of IPSP,
because they are not related.
c) Whether relaying entity is called SGP or ASP is not very important,
important is that it follows the procedures defined in the specification.

I know relaying in SUA is kind of fuzzy right now, but I am with you on the
same boat on that issue.

Thanks,
Tolga

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


Tolga,

Please allow me to say that now I am totally confused!

You say that IPSP cannot relay SUA traffic. At the same time SGP can "host
local applications" and is the only process that relays according to your
opinion.

What is the difference then between IPSP1-IPSP_with relay-IPSP2 from
SGP1-SGP_with_relay-SGP2 ???

In the latter case SGP1 and ! SGP2 host local applications in the IP domain
and do not have any access to the calssical SS7 netowork (therefore do
actually behave as an IPSP processes)!

But then we finish at the starting point -> AS/RC concept is originally
desinged for direct-to-direct communications and relay seems not to be
elaborated in the SUA RFC at all (e.g. how should relay behave in the
environment of multiple AS'es/RC'es per signalliong processes etc...)! All
of your answers to my previous questions are based on the assumption that
IPSP cannot relay SUA traffic!

Take your time and please help me to understand SUA Relay! Looking into the
SIGTRAN mail archieve this seems to bother many people.

This relay thing in SUA seems to be totally incompatible with AS/RC concept
which is copy/pasted from the M3UA specification which on the other hand
forbids relay!

kind regards/ Stanislav



Tolga Asveren wrote:
Stanislav,


-----Or! iginal Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Sent: Wednesday, December 14, 2005 4:50 PM
To: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

Thank You very much! Now it is clear!

Could You please explicilty confirm or denay with TRUE or FALSE the
following statement:

Once a message comes from SS7 to SUA network it can be relayed only at two
places, namely SGW and ASP but not at IPSP place.
[TOLGA]Actually, if an ASP is capable of relaying messages I would call it
SGP, so I would say only a SGP is capable of relaying messages -please note
that a SGP can host local applications-. It is true that IPSP can't realy
messages.

with very best regards/ Stanislav



Tolga Asveren wrote:
Stanislav,

If the whole SPMC is down (ISUP, SCCP etc..) then you send TFC. Otherwise,
you don't send anything, just mark the user part, which ! is down as
"unavailable". If a message from SS7 network arrives to that user part, you
reply with UPU, no different than with regular SS7 case.

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


Tolga,

You didn't understood my TFP point below -> actually I asked what if SUA
gateway looses connection to SPC in the SUA network, should it send TFP in
the MTP network?

Then you have my objection on how to indicate inaccessiblity of particular
application only (SCCP application in this case at SPC but not ISUP or BICC
at the same SPC)!

Thank You!

kind regards/ stanislav



Tolga Asveren wrote:
Stanislav,


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


Tolga,

SUA RFC:

1.3.1.2. Signalling Gateway as relay-point


"A Global Title translation is executed at the signalling gateway, before
the destination of the message can be determined. The actual location of the
SCCP-user is irrelevant to the SS7 network. GT Translation yields an "SCCP
entity set", from which an Application Server can be derived. Selection of
the Application Server is based on the SCCP called party address (and
possibly other SS7 parameters
depending on the implementation)."
[TOLGA]Check 1.4.6 as well. 1.3.1.2 is nothing else than the good old GTT.
1.4.6 talsk about the SUA specific relay functionality.

There is no word about SPC based relay in SUA gateway. If you think that SPC
relay in SUA gateway (!) is supposed to relay based on SPC is it supposed to
send TFP when! the SPC is inaccessible (i.e. to behave as MTP STP)?
[TOLGA]You should use SUA defined SSNM messages.

If so how you can inidcate inaccessiblity of only SCCP applications by means
of TFP? MTP message TFP indicates inaccessiblity to all user parts not just
particular one!

You are saying that IPSP does not contain relay. Are you saying that only
ASP can relay to the final IPSP which cannot relay further?
[TOLGA]An IPSP communicated only with another IPSP. Any other type of
communication requires interworking on application level.

thank You!

/stanislav

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www1.ietf.org/mailman/listinfo/sigtran

[Tolga Asveren]

Stanislav,

Actually I believe I couldn't express my opinion well causing misleading you
a bit, but SUA relay probably is more like SG-SG, but mimics SCCP procedures
rather than MTP3, at least this is my understanding.

     Thanks,
     Tolga

-----Original Message-----
From: sigtran-bounces@... [mailto:sigtran-bounces@...]On Behalf Of
Stanislav Ivanovich
Sent: Friday, December 16, 2005 11:18 AM
To: SIGTRAN
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Hello SIGTRAN community,

I have had a discussion with Tolga Asveren about fundamental concepts around
SUA Relay. I have noticed that most of my communication with him was held
outside the SIGTRAN community mailing list (I addressed him directly)
therefore I correct this now. You can look for the first part of the
discussion at
http://www1.ietf.org/mail-archive/web/sigtran/current/msg05525.html and the
rest is below.

My point is that SUA Relay hardly fits into the AS/RC concept which is
originally designed for SGP-ASP and IPSP-IPSP (direct) communication. The
point is that if the applications are in IP network there is no relay
between them on the level of SUA protocol.

However Tolga convinced me that actually SUA Relay means:

ASP1-SGP-ASP2

I do not have conceptual problems with this and I accept this! Note also
that this means that one can build SUA relay between two IP resident
applications only in one relay stage, since SGP-SGP is not part of SUA
specification!

However I have tremendous problems with something like this:

IPSP1-IPSP_R1-IPSP_R2-IPSP_R3-........-IPSP2

where IPSP_Rx stands for IPSP process equipped with relay capability.

The problems get even bigger if one wants to build the whole (fully or
partly) meshed network of IPSP_Rx processes. This is impossible to
incorporate into the AS/RC concept which is normally used on the IPSP-IPSP
interface.

I would like to hear what other members of the SIGTRAN community think about
this since by looking into the SIGTRAN mail archive I see that many peopl! e
think that SUA might relay with many IPSP processes interconnected what
seems to me hardly compatible with fundamental AS/RC concepts.

Please look into the mail below for discussion.


I would also like to draw attention to the unofficial draft being written by
Tolga for SG-SG communication for M3UA (see mail below for address where you
can fetch it).

I think that this concept is especially usefully for SUA and should be
extended to SUA as well. For example if one wants to have GT translation
distributed in space (i.e. to build network of relay nodes that are to
perform GT translation) then we need SGP-SGP communication.

I also think that we should have AS/RC concepts kept away from the SGP-SGP
interface.

Currently (according to Tolga's view, and my also) only ASP1-SGP-AS2 relay
is possible in SUA with jus! t one relay stage.

I kindly ask SIGTRAN comunity to give us its opinion.

best regards/ Stanislav Ivanovich



Tolga Asveren <asveren@...> wrote:
Stanislav,

SG-SG work is going on, initially for M3UA but it hopefully will be extended
for SUA as well. Currently it is not an official WG-item, if you think it is
some useful concept, you can express yur opinion in the SIGTRAN WG mailing
list. For a draft to become WG-item, there should be enough interested
parties in it and right now we probably are short of it.

The link for M3UA SG-SG draft is:
http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uasgsg-00.txt

Tolga
-----Original Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Se! nt: Thursday, December 15, 2005 1:43 PM
To: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

Now I see Your point and I must admit that I fully agree with You!

I have a proposal how to define SUA relay and at the same time be fully
compatible with the AS/RC concepts which are originally tailored for SGP-ASP
and IPSP-IPSP communication without any relay (except in SGP between SS7 and
IP).

My essential point here is that if one wants to incorporate a relay process
in between SGP and ASP or two IPSP'es he/she will finish in tremendous
conceptual problems especially in the environment of multiple processes and
multiple AS'es per signalling process environments.

I am not saying that it is impossible to define SRP1 (SUA Relay Process in
between SGP-ASP) and SRP2 (SUA Relay Process in between IPSP-IPSP) which are
both to use AS concepts. For example SRP1 would mimic an SGP (or maybe even
several SGP's) when communicating with an ASP and ASP (or maybe even several
APS'es) when communicating with an SGP.

But this seems to be feasible only for very simple configurations without
many AS'es and processes involved.

Even more if we allow a relay process which will send SSNM messages to an
IPSP this could be considered as a violation of fundamanetal AS principles
since exchange of this calss of messages (expcet of course SCON) is not
allowed there.

One might then say: "OK if a relay proces is supposed to send SSNM messages
then instaed of IPSP we have ASP".

We need just one additional step to find the soltuinon -> the SCCP alike
relay (GT or maybe even SPC based) is essentialy possible as you once said
between SGP processes.

Thus we finish in this configuration:

ASP1---SGP1--------SGP2---ASP2

In this case we equip (define) the SGP'es with procedures to relay from IP
to IP network! (i.e. access to SS7 network is not always necessary) and
that's it!

However it is essentially important to note that in this case AS concpet
finishes/terminates on the SGP'es. In another words we have AS1 served by
ASP1 and "terminated" at SGP1 and AS2 served by ASP2 and "terminated" by
SGP2. But SGP'es do not use AS concept for SGP-SGP communication but instead
use SCTP associations like SCCP uses MTP links (or Route Sets.... whatever).

In this way the construction is closed and the relay perfectly fits into SUA
network and is comaptible with AS concepts which are kept away from the
SGP-SGP interfaces. And the original prinicples of AS are kept intact and
consistent!

What do You think?

best regards/ Stanislav


Tolga Asveren wrote:
Stanislav,

a)Both for SUA or M3UA, IPSPs can't relay.
b) Relaying in SUA is *NOT* IPSP communication and its details are not well
defined, but I don't se! e why it should effect ones understanding of IPSP,
because they are not related.
c) Whether relaying entity is called SGP or ASP is not very important,
important is that it follows the procedures defined in the specification.

I know relaying in SUA is kind of fuzzy right now, but I am with you on the
same boat on that issue.

Thanks,
Tolga

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


Tolga,

Please allow me to say that now I am totally confused!

You say that IPSP cannot relay SUA traffic. At the same time SGP can "host
local applications" and is the only process that relays according to your
opinion.

What is the difference then between IPSP1-IPSP_with relay-IPSP2 from
SGP1-SGP_with_relay-SGP2 ???

In the latter case SGP1 and ! SGP2 host local applications in the IP domain
and do not have any access to the calssical SS7 netowork (therefore do
actually behave as an IPSP processes)!

But then we finish at the starting point -> AS/RC concept is originally
desinged for direct-to-direct communications and relay seems not to be
elaborated in the SUA RFC at all (e.g. how should relay behave in the
environment of multiple AS'es/RC'es per signalliong processes etc...)! All
of your answers to my previous questions are based on the assumption that
IPSP cannot relay SUA traffic!

Take your time and please help me to understand SUA Relay! Looking into the
SIGTRAN mail archieve this seems to bother many people.

This relay thing in SUA seems to be totally incompatible with AS/RC concept
which is copy/pasted from the M3UA specification which on the other hand
forbids relay!

kind regards/ Stanislav



Tolga Asveren wrote:
Stanislav,


-----Or! iginal Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Sent: Wednesday, December 14, 2005 4:50 PM
To: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

Thank You very much! Now it is clear!

Could You please explicilty confirm or denay with TRUE or FALSE the
following statement:

Once a message comes from SS7 to SUA network it can be relayed only at two
places, namely SGW and ASP but not at IPSP place.
[TOLGA]Actually, if an ASP is capable of relaying messages I would call it
SGP, so I would say only a SGP is capable of relaying messages -please note
that a SGP can host local applications-. It is true that IPSP can't realy
messages.

with very best regards/ Stanislav



Tolga Asveren wrote:
Stanislav,

If the whole SPMC is down (ISUP, SCCP etc..) then you send TFC. Otherwise,
you don't send anything, just mark the user part, which ! is down as
"unavailable". If a message from SS7 network arrives to that user part, you
reply with UPU, no different than with regular SS7 case.

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


Tolga,

You didn't understood my TFP point below -> actually I asked what if SUA
gateway looses connection to SPC in the SUA network, should it send TFP in
the MTP network?

Then you have my objection on how to indicate inaccessiblity of particular
application only (SCCP application in this case at SPC but not ISUP or BICC
at the same SPC)!

Thank You!

kind regards/ stanislav



Tolga Asveren wrote:
Stanislav,


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


Tolga,

SUA RFC:

1.3.1.2. Signalling Gateway as relay-point


"A Global Title translation is executed at the signalling gateway, before
the destination of the message can be determined. The actual location of the
SCCP-user is irrelevant to the SS7 network. GT Translation yields an "SCCP
entity set", from which an Application Server can be derived. Selection of
the Application Server is based on the SCCP called party address (and
possibly other SS7 parameters
depending on the implementation)."
[TOLGA]Check 1.4.6 as well. 1.3.1.2 is nothing else than the good old GTT.
1.4.6 talsk about the SUA specific relay functionality.

There is no word about SPC based relay in SUA gateway. If you think that SPC
relay in SUA gateway (!) is supposed to relay based on SPC is it supposed to
send TFP when! the SPC is inaccessible (i.e. to behave as MTP STP)?
[TOLGA]You should use SUA defined SSNM messages.

If so how you can inidcate inaccessiblity of only SCCP applications by means
of TFP? MTP message TFP indicates inaccessiblity to all user parts not just
particular one!

You are saying that IPSP does not contain relay. Are you saying that only
ASP can relay to the final IPSP which cannot relay further?
[TOLGA]An IPSP communicated only with another IPSP. Any other type of
communication requires interworking on application level.

thank You!

/stanislav
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com



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

[Tolga Asveren]

Stanislav,

-----Original Message-----
From: sigtran-bounces@... [mailto:sigtran-bounces@...]On Behalf Of
Stanislav Ivanovich
Sent: Friday, December 16, 2005 1:32 PM
To: SIGTRAN
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

As You once said it does not matter how we shall call something but what are
the procedures that should be applied in between two processes.

In the mail below You told me that SUA Relay is actually SGP-ASP relay.
Please see Your answer to Brian F. G. Bidulock on this matter. What did You
actually mean by this?
[TOLGA]No, what I mean is that SUA relay is not related with IPSP behavior.
As far as I understand it should be something similar like SUA SG-SG
communication, kibd of like a SCCP-router (let me say that this statement is
highly speculative).

You also insisted that there is no SUA relay in IPSP processes (i.e. IPSP
processes should not send DUNA, DAVA etc.. messages). In Your answer to Ilie
Glib on http://www1.ietf.org/mail-archive/web/sigtran/current/msg05492.html
I see that You confirm Brian's point that there are no DUNA, DAVA etc..
messages between two IPSP processes. Could You also comment this as well,
what did You mean actually?
[TOLGA]Yes, there is no relaying for IPSP, neither for M3UA nor for SUA.

I have taken a brief look at your SG-SG draft paper a! nd I see that there
is ASPAC message there in between two SGP processes.

However is this ASPAC message the ASP_ACTIVE of M3UA?
[TOLGA]No, it signals end of PC information update phase, this is explained
in the draft.

If it is so what is the RC value to be sent?

If we have a network of SGP processes fully or partly meshed and there are
many AS'es served by the application processes connected to SGP'es what
should RC value on the SGP-SGP interface represent at all?
(especially in multiple RC scenarios)
[TOLGA]SG-SG communciation for M3UA is based on PCs, there are no RCs. For
SUA I am not sure, it could be PC+SSN , but as I said for SUA case I am just
speculating here.

On SGP-ASP and IPSP-IPSP interfaces the RC values represent AS'es. An AS is
an application served by one or several application processes (ASP'es or
IPSP'es).

Therefore I think that AS concept should terminate at ASP-SGP interface and
not be visible on the SGP-SGP interface at all because applications are only
visible on SGP-ASP and IPSP-IPSP interfaces.
[TOLGA]This is precisely how it is in SG-SG draft.

Afterall if SGP-SGP communication is to model MTP3<->MTP3 (or SCCP<->SCCP)
communication then you do not indicate RC but MTP destinations (or SCCP
subsystems). What would mean to indicate inaccessibility for DPC for RC1 but
not for RC2 between two SGP processes?
[TOLGA]Yes, you are right.

Your draft paper is not explicit in this very important aspect but if You
really think that AS/RC should be part of SGP-SGP communication then the
ultimate question is -> Why do You actually need RC support in between
SGP-SGP for?
[TOLGA]I agree with you that RC concept is not necessary for SG-SG
communication but I disagree with you that this is not well-specified in the
draft:


1.3 Architecture
 SG-SG communication management is based mainly on SSNM as defined in
   M3UA.  Communication of peers is in PC granularity.

2.2.  Routing Keys and Routing Context
        There is no Routing Context/Routing Key concept present in SG-SG
communication.


kind regards/ Stanislav Ivanovich



Tolga Asveren <asveren@...> wrote:
Stanislav,

Actually I believe I couldn't express my opinion well causing misleading you
a bit, but SUA relay probably is more like SG-S! G, but mimics SCCP
procedures
rather than MTP3, at least this is my understanding.

Thanks,
Tolga

-----Original Message-----
From: sigtran-bounces@... [mailto:sigtran-bounces@...]On Behalf Of
Stanislav Ivanovich
Sent: Friday, December 16, 2005 11:18 AM
To: SIGTRAN
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Hello SIGTRAN community,

I have had a discussion with Tolga Asveren about fundamental concepts around
SUA Relay. I have noticed that most of my communication with him was held
outside the SIGTRAN community mailing list (I addressed him directly)
therefore I correct this now. You can look for the first part of the
discussion at
http://www1.ietf.org/mail-archive/web/sigtran/current/msg05525.html and the
rest is below.

My point is that SUA Relay hardly fits into the AS/RC concept which is
originally designed for SGP-ASP and IPSP-IPSP (direct) communication. The
point is th! at if the applications are in IP network there is no relay
between them on the level of SUA protocol.

However Tolga convinced me that actually SUA Relay means:

ASP1-SGP-ASP2

I do not have conceptual problems with this and I accept this! Note also
that this means that one can build SUA relay between two IP resident
applications only in one relay stage, since SGP-SGP is not part of SUA
specification!

However I have tremendous problems with something like this:

IPSP1-IPSP_R1-IPSP_R2-IPSP_R3-........-IPSP2

where IPSP_Rx stands for IPSP process equipped with relay capability.

The problems get even bigger if one wants to build the whole (fully or
partly) meshed network of IPSP_Rx processes. This is impossible to
incorporate into the AS/RC concept which is normally used on the IPSP-IPSP
interface.

I would like to hear what other members of the SIGTRAN community think about
this since by looking into the SIGTRAN ! mail archive I see that many peopl!
e
think that SUA might relay with many IPSP processes interconnected what
seems to me hardly compatible with fundamental AS/RC concepts.

Please look into the mail below for discussion.


I would also like to draw attention to the unofficial draft being written by
Tolga for SG-SG communication for M3UA (see mail below for address where you
can fetch it).

I think that this concept is especially usefully for SUA and should be
extended to SUA as well. For example if one wants to have GT translation
distributed in space (i.e. to build network of relay nodes that are to
perform GT translation) then we need SGP-SGP communication.

I also think that we should have AS/RC concepts kept away from the SGP-SGP
interface.

Currently (according to Tolga's view, and my also) only ASP1-SGP-AS2 relay
is possible in SUA with jus! t one relay stage.

I kindly ask SIGTRAN comunity to give us its opinion.

best regards/ Stanislav Ivanovich



Tolga Asveren wrote:
Stanislav,

SG-SG work is going on, initially for M3UA but it hopefully will be extended
for SUA as well. Currently it is not an official WG-item, if you think it is
some useful concept, you can express yur opinion in the SIGTRAN WG mailing
list. For a draft to become WG-item, there should be enough interested
parties in it and right now we probably are short of it.

The link for M3UA SG-SG draft is:
http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uasgsg-00.txt

Tolga
-----Original Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Se! nt: Thursday, December 15, 2005 1:43 PM
To: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

Now I see Your point and I must admit that I fully agree with You!

I have a proposal how to define! SUA relay and at the same time be fully
compatible with the AS/RC concepts which are originally tailored for SGP-ASP
and IPSP-IPSP communication without any relay (except in SGP between SS7 and
IP).

My essential point here is that if one wants to incorporate a relay process
in between SGP and ASP or two IPSP'es he/she will finish in tremendous
conceptual problems especially in the environment of multiple processes and
multiple AS'es per signalling process environments.

I am not saying that it is impossible to define SRP1 (SUA Relay Process in
between SGP-ASP) and SRP2 (SUA Relay Process in between IPSP-IPSP) which are
both to use AS concepts. For example SRP1 would mimic an SGP (or maybe even
several SGP's) when communicating with an ASP and ASP (or maybe even several
APS'es) when communicating with an SGP.

But this seems to be feasible only for very simple configurations without
many AS'es and processes involved.

Eve! n more if we allow a relay process which will send SSNM messages to an
IPSP this could be considered as a violation of fundamanetal AS principles
since exchange of this calss of messages (expcet of course SCON) is not
allowed there.

One might then say: "OK if a relay proces is supposed to send SSNM messages
then instaed of IPSP we have ASP".

We need just one additional step to find the soltuinon -> the SCCP alike
relay (GT or maybe even SPC based) is essentialy possible as you once said
between SGP processes.

Thus we finish in this configuration:

ASP1---SGP1--------SGP2---ASP2

In this case we equip (define) the SGP'es with procedures to relay from IP
to IP network! (i.e. access to SS7 network is not always necessary) and
that's it!

However it is essentially important to note that in this case AS concpet
finishes/terminates on the SGP'es. In another words we have AS1 served by
ASP1 and "terminated" at SGP1 and ! AS2 served by ASP2 and "terminated" by
SGP2. But SGP'es do not use AS concept for SGP-SGP communication but instead
use SCTP associations like SCCP uses MTP links (or Route Sets.... whatever).

In this way the construction is closed and the relay perfectly fits into SUA
network and is comaptible with AS concepts which are kept away from the
SGP-SGP interfaces. And the original prinicples of AS are kept intact and
consistent!

What do You think?

best regards/ Stanislav


Tolga Asveren wrote:
Stanislav,

a)Both for SUA or M3UA, IPSPs can't relay.
b) Relaying in SUA is *NOT* IPSP communication and its details are not well
defined, but I don't se! e why it should effect ones understanding of IPSP,
because they are not related.
c) Whether relaying entity is called SGP or ASP is not very important,
important is that it follows the procedures defined in the specification.

I know relaying in SUA is kind of fuzzy ! right now, but I am with you on
the
same boat on that issue.

Thanks,
Tolga

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


Tolga,

Please allow me to say that now I am totally confused!

You say that IPSP cannot relay SUA traffic. At the same time SGP can "host
local applications" and is the only process that relays according to your
opinion.

What is the difference then between IPSP1-IPSP_with relay-IPSP2 from
SGP1-SGP_with_relay-SGP2 ???

In the latter case SGP1 and ! SGP2 host local applications in the IP domain
and do not have any access to the calssical SS7 netowork (therefore do
actually behave as an IPSP processes)!

But then we finish at the starting point -> AS/RC concept is originally
desinged for direct-to-direct communications and relay seems not to be
elaborated in the SUA RFC at all (e.g. how should relay behave in the
environment of multiple AS'es/RC'es per signalliong processes etc...)! All
of your answers to my previous questions are based on the assumption that
IPSP cannot relay SUA traffic!

Take your time and please help me to understand SUA Relay! Looking into the
SIGTRAN mail archieve this seems to bother many people.

This relay thing in SUA seems to be totally incompatible with AS/RC concept
which is copy/pasted from the M3UA specification which on the other hand
forbids relay!

kind regards/ Stanislav



Tolga Asveren wrote:
Stanislav,


-----Or! iginal Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Sent: Wednesday, December 14, 2005 4:50 PM
To: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

Thank You very much! ! Now it is clear!

Could You please explicilty confirm or denay with TRUE or FALSE the
following statement:

Once a message comes from SS7 to SUA network it can be relayed only at two
places, namely SGW and ASP but not at IPSP place.
[TOLGA]Actually, if an ASP is capable of relaying messages I would call it
SGP, so I would say only a SGP is capable of relaying messages -please note
that a SGP can host local applications-. It is true that IPSP can't realy
messages.

with very best regards/ Stanislav



Tolga Asveren wrote:
Stanislav,

If the whole SPMC is down (ISUP, SCCP etc..) then you send TFC. Otherwise,
you don't send anything, just mark the user part, which ! is down as
"unavailable". If a message from SS7 network arrives to that user part, you
reply with UPU, no different than with regular SS7 case.

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


Tolga,

You didn't understood my TFP point below -> actually I asked what if SUA
gateway looses connection to SPC in the SUA network, should it send TFP in
the MTP network?

Then you have my objection on how to indicate inaccessiblity of particular
application only (SCCP application in this case at SPC but not ISUP or BICC
at the same SPC)!

Thank You!

kind regards/ stanislav



Tolga Asveren wrote:
Stanislav,


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


Tolga,

SUA RFC:

1.3.1.2. Signalling Gateway as relay-point


"A Glo! bal Title translation is executed at the signalling gateway, before
the destination of the message can be determined. The actual location of the
SCCP-user is irrelevant to the SS7 network. GT Translation yields an "SCCP
entity set", from which an Application Server can be derived. Selection of
the Application Server is based on the SCCP called party address (and
possibly other SS7 parameters
depending on the implementation)."
[TOLGA]Check 1.4.6 as well. 1.3.1.2 is nothing else than the good old GTT.
1.4.6 talsk about the SUA specific relay functionality.

There is no word about SPC based relay in SUA gateway. If you think that SPC
relay in SUA gateway (!) is supposed to relay based on SPC is it supposed to
send TFP when! the SPC is inaccessible (i.e. to behave as MTP STP)?
[TOLGA]You should use SUA defined SSNM messages.

If so how you can inidcate inaccessiblity of only SCCP applications by means
of TFP? MTP message TFP indicates inacc! essiblity to all user parts not
just
particular one!

You are saying that IPSP does not contain relay. Are you saying that only
ASP can relay to the final IPSP which cannot relay further?
[TOLGA]An IPSP communicated only with another IPSP. Any other type of
communication requires interworking on application level.

thank You!

/stanislav
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com



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



__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com



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

[Stanislav Ivanovich]

Tolga,

 

As You once said it does not matter how we shall call something but what are the procedures that should be applied in between two processes.

 

In the mail below You told me that SUA Relay is actually SGP-ASP relay. Please see Your answer to Brian F. G. Bidulock on this matter. What did You actually mean by this?

 

You also insisted that there is no SUA relay in IPSP processes (i.e. IPSP processes should not send DUNA, DAVA etc.. messages). In Your answer to Ilie Glib on http://www1.ietf.org/mail-archive/web/sigtran/current/msg05492.html I see that You confirm Brian's point that there are no DUNA, DAVA etc.. messages between two IPSP processes. Could You also comment this as well, what did You mean actually?

 

I have taken a brief look at your SG-SG draft paper a! nd I see that there is ASPAC message there in between two SGP processes.

 

However is this ASPAC message the ASP_ACTIVE of M3UA?

 

If it is so what is the RC value to be sent?

 

If we have a network of SGP processes fully or partly meshed and there are many AS'es served by the application processes connected to SGP'es what should RC value on the SGP-SGP interface represent at all?

(especially in multiple RC scenarios)

 

On SGP-ASP and IPSP-IPSP interfaces the RC values represent AS'es. An AS is an application served by one or several application processes (ASP'es or IPSP'es).

 

Therefore I think that AS concept should terminate at ASP-SGP interface and not be visible on the SGP-SGP interface at all because applications are only visible on SGP-ASP and IPSP-IPSP interfaces.

 

Afterall if SGP-SGP communication is to model MTP3<->MTP3 (or SCCP<->SCCP) communication then you do not indicate RC but MTP destinations (or SCCP subsystems). What would mean to indicate inaccessibility for DPC for RC1 but not for RC2 between two SGP processes?

 

Your draft paper is not explicit in this very important aspect but if You really think that AS/RC should be part of SGP-SGP communication then the ultimate question is -> Why do You actually need RC support in between SGP-SGP for?

 

kind regards/ Stanislav Ivanovich

 

Tolga Asveren <asveren@...> wrote:

Stanislav,

Actually I believe I couldn't express my opinion well causing misleading you
a bit, but SUA relay probably is more like SG-S! G, but mimics SCCP procedures
rather than MTP3, at least this is my understanding.

Thanks,
Tolga

-----Original Message-----
From: sigtran-bounces@... [mailto:sigtran-bounces@...]On Behalf Of
Stanislav Ivanovich
Sent: Friday, December 16, 2005 11:18 AM
To: SIGTRAN
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Hello SIGTRAN community,

I have had a discussion with Tolga Asveren about fundamental concepts around
SUA Relay. I have noticed that most of my communication with him was held
outside the SIGTRAN community mailing list (I addressed him directly)
therefore I correct this now. You can look for the first part of the
discussion at
http://www1.ietf.org/mail-archive/web/sigtran/current/msg05525.html and the
rest is below.

My point is that SUA Relay hardly fits into the AS/RC concept which is
originally designed for SGP-ASP and IPSP-IPSP (direct) communication. The
point is th! at if the applications are in IP network there is no relay
between them on the level of SUA protocol.

However Tolga convinced me that actually SUA Relay means:

ASP1-SGP-ASP2

I do not have conceptual problems with this and I accept this! Note also
that this means that one can build SUA relay between two IP resident
applications only in one relay stage, since SGP-SGP is not part of SUA
specification!

However I have tremendous problems with something like this:

IPSP1-IPSP_R1-IPSP_R2-IPSP_R3-........-IPSP2

where IPSP_Rx stands for IPSP process equipped with relay capability.

The problems get even bigger if one wants to build the whole (fully or
partly) meshed network of IPSP_Rx processes. This is impossible to
incorporate into the AS/RC concept which is normally used on the IPSP-IPSP
interface.

I would like to hear what other members of the SIGTRAN community think about
this since by looking into the SIGTRAN ! mail archive I see that many peopl! e
think that SUA might relay with many IPSP processes interconnected what
seems to me hardly compatible with fundamental AS/RC concepts.

Please look into the mail below for discussion.


I would also like to draw attention to the unofficial draft being written by
Tolga for SG-SG communication for M3UA (see mail below for address where you
can fetch it).

I think that this concept is especially usefully for SUA and should be
extended to SUA as well. For example if one wants to have GT translation
distributed in space (i.e. to build network of relay nodes that are to
perform GT translation) then we need SGP-SGP communication.

I also think that we should have AS/RC concepts kept away from the SGP-SGP
interface.

Currently (according to Tolga's view, and my also) only ASP1-SGP-AS2 relay
is possible in SUA with jus! t one relay stage.

I kindly ask SIGTRAN comunity to give us its opinion.

best regards/ Stanislav Ivanovich



Tolga Asveren wrote:
Stanislav,

SG-SG work is going on, initially for M3UA but it hopefully will be extended
for SUA as well. Currently it is not an official WG-item, if you think it is
some useful concept, you can express yur opinion in the SIGTRAN WG mailing
list. For a draft to become WG-item, there should be enough interested
parties in it and right now we probably are short of it.

The link for M3UA SG-SG draft is:
http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uasgsg-00.txt

Tolga
-----Original Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Se! nt: Thursday, December 15, 2005 1:43 PM
To: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

Now I see Your point and I must admit that I fully agree with You!

I have a proposal how to define! SUA relay and at the same time be fully
compatible with the AS/RC concepts which are originally tailored for SGP-ASP
and IPSP-IPSP communication without any relay (except in SGP between SS7 and
IP).

My essential point here is that if one wants to incorporate a relay process
in between SGP and ASP or two IPSP'es he/she will finish in tremendous
conceptual problems especially in the environment of multiple processes and
multiple AS'es per signalling process environments.

I am not saying that it is impossible to define SRP1 (SUA Relay Process in
between SGP-ASP) and SRP2 (SUA Relay Process in between IPSP-IPSP) which are
both to use AS concepts. For example SRP1 would mimic an SGP (or maybe even
several SGP's) when communicating with an ASP and ASP (or maybe even several
APS'es) when communicating with an SGP.

But this seems to be feasible only for very simple configurations without
many AS'es and processes involved.

Eve! n more if we allow a relay process which will send SSNM messages to an
IPSP this could be considered as a violation of fundamanetal AS principles
since exchange of this calss of messages (expcet of course SCON) is not
allowed there.

One might then say: "OK if a relay proces is supposed to send SSNM messages
then instaed of IPSP we have ASP".

We need just one additional step to find the soltuinon -> the SCCP alike
relay (GT or maybe even SPC based) is essentialy possible as you once said
between SGP processes.

Thus we finish in this configuration:

ASP1---SGP1--------SGP2---ASP2

In this case we equip (define) the SGP'es with procedures to relay from IP
to IP network! (i.e. access to SS7 network is not always necessary) and
that's it!

However it is essentially important to note that in this case AS concpet
finishes/terminates on the SGP'es. In another words we have AS1 served by
ASP1 and "terminated" at SGP1 and ! AS2 served by ASP2 and "terminated" by
SGP2. But SGP'es do not use AS concept for SGP-SGP communication but instead
use SCTP associations like SCCP uses MTP links (or Route Sets.... whatever).

In this way the construction is closed and the relay perfectly fits into SUA
network and is comaptible with AS concepts which are kept away from the
SGP-SGP interfaces. And the original prinicples of AS are kept intact and
consistent!

What do You think?

best regards/ Stanislav


Tolga Asveren wrote:
Stanislav,

a)Both for SUA or M3UA, IPSPs can't relay.
b) Relaying in SUA is *NOT* IPSP communication and its details are not well
defined, but I don't se! e why it should effect ones understanding of IPSP,
because they are not related.
c) Whether relaying entity is called SGP or ASP is not very important,
important is that it follows the procedures defined in the specification.

I know relaying in SUA is kind of fuzzy ! right now, but I am with you on the
same boat on that issue.

Thanks,
Tolga

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


Tolga,

Please allow me to say that now I am totally confused!

You say that IPSP cannot relay SUA traffic. At the same time SGP can "host
local applications" and is the only process that relays according to your
opinion.

What is the difference then between IPSP1-IPSP_with relay-IPSP2 from
SGP1-SGP_with_relay-SGP2 ???

In the latter case SGP1 and ! SGP2 host local applications in the IP domain
and do not have any access to the calssical SS7 netowork (therefore do
actually behave as an IPSP processes)!

But then we finish at the starting point -> AS/RC concept is originally
desinged for direct-to-direct communications and relay seems not to be
elaborated in the SUA RFC at all (e.g. how should relay behave in the
environment of multiple AS'es/RC'es per signalliong processes etc...)! All
of your answers to my previous questions are based on the assumption that
IPSP cannot relay SUA traffic!

Take your time and please help me to understand SUA Relay! Looking into the
SIGTRAN mail archieve this seems to bother many people.

This relay thing in SUA seems to be totally incompatible with AS/RC concept
which is copy/pasted from the M3UA specification which on the other hand
forbids relay!

kind regards/ Stanislav



Tolga Asveren wrote:
Stanislav,


-----Or! iginal Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Sent: Wednesday, December 14, 2005 4:50 PM
To: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

Thank You very much! ! Now it is clear!

Could You please explicilty confirm or denay with TRUE or FALSE the
following statement:

Once a message comes from SS7 to SUA network it can be relayed only at two
places, namely SGW and ASP but not at IPSP place.
[TOLGA]Actually, if an ASP is capable of relaying messages I would call it
SGP, so I would say only a SGP is capable of relaying messages -please note
that a SGP can host local applications-. It is true that IPSP can't realy
messages.

with very best regards/ Stanislav



Tolga Asveren wrote:
Stanislav,

If the whole SPMC is down (ISUP, SCCP etc..) then you send TFC. Otherwise,
you don't send anything, just mark the user part, which ! is down as
"unavailable". If a message from SS7 network arrives to that user part, you
reply with UPU, no different than with regular SS7 case.

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


Tolga,

You didn't understood my TFP point below -> actually I asked what if SUA
gateway looses connection to SPC in the SUA network, should it send TFP in
the MTP network?

Then you have my objection on how to indicate inaccessiblity of particular
application only (SCCP application in this case at SPC but not ISUP or BICC
at the same SPC)!

Thank You!

kind regards/ stanislav



Tolga Asveren wrote:
Stanislav,


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


Tolga,

SUA RFC:

1.3.1.2. Signalling Gateway as relay-point


"A Glo! bal Title translation is executed at the signalling gateway, before
the destination of the message can be determined. The actual location of the
SCCP-user is irrelevant to the SS7 network. GT Translation yields an "SCCP
entity set", from which an Application Server can be derived. Selection of
the Application Server is based on the SCCP called party address (and
possibly other SS7 parameters
depending on the implementation)."
[TOLGA]Check 1.4.6 as well. 1.3.1.2 is nothing else than the good old GTT.
1.4.6 talsk about the SUA specific relay functionality.

There is no word about SPC based relay in SUA gateway. If you think that SPC
relay in SUA gateway (!) is supposed to relay based on SPC is it supposed to
send TFP when! the SPC is inaccessible (i.e. to behave as MTP STP)?
[TOLGA]You should use SUA defined SSNM messages.

If so how you can inidcate inaccessiblity of only SCCP applications by means
of TFP? MTP message TFP indicates inacc! essiblity to all user parts not just
particular one!

You are saying that IPSP does not contain relay. Are you saying that only
ASP can relay to the final IPSP which cannot relay further?
[TOLGA]An IPSP communicated only with another IPSP. Any other type of
communication requires interworking on application level.

thank You!

/stanislav
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com



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

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www1.ietf.org/mailman/listinfo/sigtran

[Tolga Asveren]

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock@...]
> Sent: Friday, December 16, 2005 1:52 PM
> To: Tolga Asveren
> Cc: SIGTRAN
> Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
>
>
> Tolga,
>
> Well, no.  Unlike MTP, where the transfer function is only optionally
> equipped at specific interior nodes in the network (STPs), SCCP relay
> is possible at all nodes in the network (including endpoints).  Therefore
> M3UA can treat the network as point to point (i.e. like all F-links with
> no STPs) but SUA cannot treat the network as having no relay points.

[TOLGA]Yes, I agree that SCCP itself has transfer capability, but SUA-IPSP
does not have SCCP layer, it just provides the same interface as SCCP to its
users. I don't think that SUA MUST support relaying can be concluded
directly from the transport functionality of SCCP. OTOH, I agree that
relaying is a useful concept even in IP-transport case from
management/maintenence etc... point of view, both for SUA and M3UA.
>
> Therefore, SUA IPSPs must support relay to support SCCP-Users.
[TOLGA]I believe for SUA, all the relationship between SUA-Relay and
SUA-IPSP should be thought/defined carefully. My point of view is that SUA
IPSP does not support relaying. There is no SCCP layer in an SUA-IPSP, OTOH
a SUA-SG has SCCP layer. My undertsanding is:
SUA-Relay ==> SG-SG for SUA (based on SCCP constructs), supports relaying.
SUA-IPSP ==> Direct communication between two SUA users, does not support
relaying.

Let me reiterate that this is just my own understanding ;-)

>
> --brian
>
> Tolga Asveren wrote:                               (Fri, 16 Dec
> 2005 11:28:33)
> > Stanislav,
> >
> > Actually I believe I couldn't express my opinion well causing
> misleading you
> > a bit, but SUA relay probably is more like SG-SG, but mimics
> SCCP procedures
> > rather than MTP3, at least this is my understanding.
> >
> >      Thanks,
> >      Tolga
> >
>
> --
> Brian F. G. Bidulock
> bidulock@...
> http://www.openss7.org/
>

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

[Brian F. G. Bidulock]

Tolga,

Well, no.  Unlike MTP, where the transfer function is only optionally
equipped at specific interior nodes in the network (STPs), SCCP relay
is possible at all nodes in the network (including endpoints).  Therefore
M3UA can treat the network as point to point (i.e. like all F-links with
no STPs) but SUA cannot treat the network as having no relay points.

Therefore, SUA IPSPs must support relay to support SCCP-Users.

--brian

Tolga Asveren wrote:                               (Fri, 16 Dec 2005 11:28:33)
> Stanislav,
>
> Actually I believe I couldn't express my opinion well causing misleading you
> a bit, but SUA relay probably is more like SG-SG, but mimics SCCP procedures
> rather than MTP3, at least this is my understanding.
>
>      Thanks,
>      Tolga
>

--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/

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

[Tolga Asveren]

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock@...]
> Sent: Friday, December 16, 2005 2:38 PM
> To: Tolga Asveren
> Cc: sigtran@...
> Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
>
>
> Tolga,
>
> SCCP also supports relay from SCCP-User to SCCP-User.  An SUA IPSP
> must also support this, regardless of where you think it is
> functionally situated.

[TOLGA]Do you mean relaying between two local SCCP-Users?

>
> --brian
>
> Tolga Asveren wrote:                                              
>    (Fri, 16 Dec 2005 13:46:48)
> > Brian,
> >
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:bidulock@...]
> > > Sent: Friday, December 16, 2005 1:52 PM
> > > To: Tolga Asveren
> > > Cc: SIGTRAN
> > > Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
> > >
> > >
> > > Tolga,
> > >
> > > Well, no.  Unlike MTP, where the transfer function is only optionally
> > > equipped at specific interior nodes in the network (STPs), SCCP relay
> > > is possible at all nodes in the network (including
> endpoints).  Therefore
> > > M3UA can treat the network as point to point (i.e. like all
> F-links with
> > > no STPs) but SUA cannot treat the network as having no relay points.
> > [TOLGA]Yes, I agree that SCCP itself has transfer capability,
> but SUA-IPSP
> > does not have SCCP layer, it just provides the same interface
> as SCCP to its
> > users. I don't think that SUA MUST support relaying can be concluded
> > directly from the transport functionality of SCCP. OTOH, I agree that
> > relaying is a useful concept even in IP-transport case from
> > management/maintenence etc... point of view, both for SUA and M3UA.
> > >
> > > Therefore, SUA IPSPs must support relay to support SCCP-Users.
> > [TOLGA]I believe for SUA, all the relationship between SUA-Relay and
> > SUA-IPSP should be thought/defined carefully. My point of view
> is that SUA
> > IPSP does not support relaying. There is no SCCP layer in an
> SUA-IPSP, OTOH
> > a SUA-SG has SCCP layer. My undertsanding is:
> > SUA-Relay ==> SG-SG for SUA (based on SCCP constructs),
> supports relaying.
> > SUA-IPSP ==> Direct communication between two SUA users, does
> not support
> > relaying.
> >
> > Let me reiterate that this is just my own understanding ;-)
> >
>
> --
> Brian F. G. Bidulock
> bidulock@...
> http://www.openss7.org/
>

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

[Brian F. G. Bidulock]

Tolga,

SCCP also supports relay from SCCP-User to SCCP-User.  An SUA IPSP
must also support this, regardless of where you think it is
functionally situated.

--brian

Tolga Asveren wrote:                                                 (Fri, 16 Dec 2005 13:46:48)

> Brian,
>
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:bidulock@...]
> > Sent: Friday, December 16, 2005 1:52 PM
> > To: Tolga Asveren
> > Cc: SIGTRAN
> > Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
> >
> >
> > Tolga,
> >
> > Well, no.  Unlike MTP, where the transfer function is only optionally
> > equipped at specific interior nodes in the network (STPs), SCCP relay
> > is possible at all nodes in the network (including endpoints).  Therefore
> > M3UA can treat the network as point to point (i.e. like all F-links with
> > no STPs) but SUA cannot treat the network as having no relay points.
> [TOLGA]Yes, I agree that SCCP itself has transfer capability, but SUA-IPSP
> does not have SCCP layer, it just provides the same interface as SCCP to its
> users. I don't think that SUA MUST support relaying can be concluded
> directly from the transport functionality of SCCP. OTOH, I agree that
> relaying is a useful concept even in IP-transport case from
> management/maintenence etc... point of view, both for SUA and M3UA.
> >
> > Therefore, SUA IPSPs must support relay to support SCCP-Users.
> [TOLGA]I believe for SUA, all the relationship between SUA-Relay and
> SUA-IPSP should be thought/defined carefully. My point of view is that SUA
> IPSP does not support relaying. There is no SCCP layer in an SUA-IPSP, OTOH
> a SUA-SG has SCCP layer. My undertsanding is:
> SUA-Relay ==> SG-SG for SUA (based on SCCP constructs), supports relaying.
> SUA-IPSP ==> Direct communication between two SUA users, does not support
> relaying.
>
> Let me reiterate that this is just my own understanding ;-)
>

--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/

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

[Stanislav Ivanovich]

Tolga,

 

Thank You very much!

 

I haven't read Your draft paper completely (I actually looked at only one paragraph) but I assumed that You used AS/RC concept of the SG-SG interface as well and this caused my previous mail and my concerns.

 

Now I see that You actually confirmed my point that the AS/RC concept should be kept away from the SG-SG communication.

 

Therefore I fully agree with this SG-SG concept since it provides relay in IP networks which is to be performed not only on IP level. I do think it is very useful concept and provides great opportunities for addressing scalability, flexibility, easier operation and management etc...

 

I am also convinced that any relay in the xxUA networks must be based on this SG-SG principles be that M3UA or SUA or any other xxUA.

 

 

And f! inally the most important property of the SG-SG concept is that it is fully compatible with the AS concepts which are of course used somewhere else (only on SGP-ASP and IPSP-IPSP interfaces). In another words one does not have to change AS concepts because of introduction of SG-SG communication.

 

 

Meanwhile until the SG-SG communication comes officially into SUA (or if it already there until it is better and more clearly specified) one might use ASP1-SGP-ASP2 relay. One has just to extend SGP procedures to relay not only between SS7 and IP but also IP and IP. However this extension does not require any update on the external protocol since the existing SGP-ASP protocol supports this. Only SGP procedures have to be updated. This will not be an interoperability issue!

 

Thank You Tolga once again, now I can say that I 100% agree with You!

 

with very best regards/ Stanislav Ivanovich

 

Tolga Asveren <asveren@...> wrote:

Stanislav,

-----Original Message-----
From: sigtran-bounces@... [mailto:sigtran-bounces@...]On Behalf Of
Stanislav Ivanovich
Sent: Friday, December 16, 2005 1:32 PM
To: SIGTRAN
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

As You once said it does not matter how we shall call something but what are
the procedures that should be applied in between two processes.

In the mail below You told me that SUA Relay is actually SGP-ASP relay.
Please see Your answer to Brian F. G. Bidulock on this matter. What did You
actually mean by this?
[TOLGA]No, what I mean is that SUA relay is not related with IPSP behavior.
As far as I understand it should be something similar like SUA SG-SG
communication, kibd of like a SCCP-router (let me say that this statement is
highly speculative).

You also insisted that there is no SUA relay in IPSP processes (i.e. IPSP
processes should not send DUNA, DAVA etc.. messages). In Your answer to Ilie
Glib on http://www1.ietf.org/mail-archive/web/sigtran/current/msg05492.html
I see that You confirm Brian's point that there are no DUNA, DAVA etc..
messages between two IPSP processes. Could You also comment this as well,
what did You mean actually?
[TOLGA]Yes, there is no relaying for IPSP, neither for M3UA nor for SUA.

I have taken a brief look at your SG-SG draft paper a! nd I see that there
is ASPAC message there in between two SGP processes.

However is this ASPAC message the ASP_ACTIVE of M3UA?
[TOLGA]No, it signals end of PC information update phase, this is explained
in the draft.

If it is so what is the RC value to be sent?

If we have a network of S! GP processes fully or partly meshed and there are
many AS'es served by the application processes connected to SGP'es what
should RC value on the SGP-SGP interface represent at all?
(especially in multiple RC scenarios)
[TOLGA]SG-SG communciation for M3UA is based on PCs, there are no RCs. For
SUA I am not sure, it could be PC+SSN , but as I said for SUA case I am just
speculating here.

On SGP-ASP and IPSP-IPSP interfaces the RC values represent AS'es. An AS is
an application served by one or several application processes (ASP'es or
IPSP'es).

Therefore I think that AS concept should terminate at ASP-SGP interface and
not be visible on the SGP-SGP interface at all because applications are only
visible on SGP-ASP and IPSP-IPSP interfaces.
[TOLGA]This is precisely how it is in SG-SG draft.

Afterall if SGP-SGP communication is to model MTP3<->MTP3 (or SCCP<->SCCP)
communication then you do not indicate RC but MTP destinations (or SCCP
subsystems). What would mean to indicate inaccessibility for DPC for RC1 but
not for RC2 between two SGP processes?
[TOLGA]Yes, you are right.

Your draft paper is not explicit in this very important aspect but if You
really think that AS/RC should be part of SGP-SGP communication then the
ultimate question is -> Why do You actually need RC support in between
SGP-SGP for?
[TOLGA]I agree with you that RC concept is not necessary for SG-SG
communication but I disagree with you that this is not well-specified in the
draft:


1.3 Architecture
SG-SG communication management is based mainly on SSNM as defined in
M3UA. Communication of peers is in PC granularity.

2.2. Routing Keys and Routing Context
There is no Routing Context/Routing Key concept present in SG-SG
communication.


kind regards/ Stanislav Ivanovich



Tolga Asveren wrote:
Stanislav,

Actually I believe I couldn't express my opinion well causing misleading you
a bit, but SUA relay probably is more like SG-S! G, but mimics SCCP
procedures
rather than MTP3, at least this is my understanding.

Thanks,
Tolga

-----Original Message-----
From: sigtran-bounces@... [mailto:sigtran-bounces@...]On Behalf Of
Stanislav Ivanovich
Sent: Friday, December 16, 2005 11:18 AM
To: SIGTRAN
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Hello SIGTRAN community,

I have had a discussion with Tolga Asveren about fundamental concepts around
SUA Relay. I have noticed that most of my communication with him was held
outside the SIGTRAN community mailing list (I addressed him directly)
therefore I correct this now. You can look for the first part of the
discussion at
http://www1.ietf.org/mail-archive/web/sigtran/current/msg05525.html and the!
rest is below.

My point is that SUA Relay hardly fits into the AS/RC concept which is
originally designed for SGP-ASP and IPSP-IPSP (direct) communication. The
point is th! at if the applications are in IP network there is no relay
between them on the level of SUA protocol.

However Tolga convinced me that actually SUA Relay means:

ASP1-SGP-ASP2

I do not have conceptual problems with this and I accept this! Note also
that this means that one can build SUA relay between two IP resident
applications only in one relay stage, since SGP-SGP is not part of SUA
specification!

However I have tremendous problems with something like this:

IPSP1-IPSP_R1-IPSP_R2-IPSP_R3-........-IPSP2

where IPSP_Rx stands for IPSP process equipped with relay capability.

The problems get even bigger if one wants to build the whole (fully or
partly) meshed network of IPSP_Rx processes. This is impossible to
incorporate into the AS/! RC concept which is normally used on the IPSP-IPSP
interface.

I would like to hear what other members of the SIGTRAN community think about
this since by looking into the SIGTRAN ! mail archive I see that many peopl!
e
think that SUA might relay with many IPSP processes interconnected what
seems to me hardly compatible with fundamental AS/RC concepts.

Please look into the mail below for discussion.


I would also like to draw attention to the unofficial draft being written by
Tolga for SG-SG communication for M3UA (see mail below for address where you
can fetch it).

I think that this concept is especially usefully for SUA and should be
extended to SUA as well. For example if one wants to have GT translation
distributed in space (i.e. to build network of relay nodes that are to
perform GT translation) then we need SGP-SGP communication.

I also think that we should have AS/RC concepts kept away from the SGP-SGP
interface.

Currently (according to Tolga's view, and my also) only ASP1-SGP-AS2 relay
is possible in SUA with jus! t one relay stage.

I kindly ask SIGTRAN comunity to give us its opinion.

best regards/ Stanislav Ivanovich



Tolga Asveren wrote:
Stanislav,

SG-SG work is going on, initially for M3UA but it hopefully will be extended
for SUA as well. Currently it is not an official WG-item, if you think it is
some useful concept, you can express yur opinion in the SIGTRAN WG mailing
list. For a draft to become WG-item, there should be enough interested
parties in it and right now we probably are short of it.

The link for M3UA SG-SG draft is:
http://www.ietf.org/internet-drafts/draft-asveren-sigtran-m3uasgsg-00.txt

Tolga
-----Original Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Se! nt: Thursday, December 15, 2005 1:43 PM
To: Tolga Asveren
Subje! ct: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

Now I see Your point and I must admit that I fully agree with You!

I have a proposal how to define! SUA relay and at the same time be fully
compatible with the AS/RC concepts which are originally tailored for SGP-ASP
and IPSP-IPSP communication without any relay (except in SGP between SS7 and
IP).

My essential point here is that if one wants to incorporate a relay process
in between SGP and ASP or two IPSP'es he/she will finish in tremendous
conceptual problems especially in the environment of multiple processes and
multiple AS'es per signalling process environments.

I am not saying that it is impossible to define SRP1 (SUA Relay Process in
between SGP-ASP) and SRP2 (SUA Relay Process in between IPSP-IPSP) which are
both to use AS concepts. For example SRP1 would mimic an SGP (or maybe even
several SGP's) when communicating with an ASP and ASP (or maybe e! ven several
APS'es) when communicating with an SGP.

But this seems to be feasible only for very simple configurations without
many AS'es and processes involved.

Eve! n more if we allow a relay process which will send SSNM messages to an
IPSP this could be considered as a violation of fundamanetal AS principles
since exchange of this calss of messages (expcet of course SCON) is not
allowed there.

One might then say: "OK if a relay proces is supposed to send SSNM messages
then instaed of IPSP we have ASP".

We need just one additional step to find the soltuinon -> the SCCP alike
relay (GT or maybe even SPC based) is essentialy possible as you once said
between SGP processes.

Thus we finish in this configuration:

ASP1---SGP1--------SGP2---ASP2

In this case we equip (define) the SGP'es with procedures to relay from IP
to IP network! (i.e. access to SS7 network is not always necessary) and
that's it!

However it is essentially important to note that in this case AS concpet
finishes/terminates on the SGP'es. In another words we have AS1 served by
ASP1 and "terminated" at SGP1 and ! AS2 served by ASP2 and "terminated" by
SGP2. But SGP'es do not use AS concept for SGP-SGP communication but instead
use SCTP associations like SCCP uses MTP links (or Route Sets.... whatever).

In this way the construction is closed and the relay perfectly fits into SUA
network and is comaptible with AS concepts which are kept away from the
SGP-SGP interfaces. And the original prinicples of AS are kept intact and
consistent!

What do You think?

best regards/ Stanislav


Tolga Asveren wrote:
Stanislav,

a)Both for SUA or M3UA, IPSPs can't relay.
b) Relaying in SUA is *NOT* IPSP communication and its details are not well
defined, but I don't se! e why it should effect ones understanding of IPSP,
because they are not related.
c) Whether relaying entity is called SGP or ASP is not very important,
important is that it follows the procedures defined in the specification.

I know relaying in SUA is kind of fuzzy ! right now, but I am with you on
the
same boat on that issue.

Thanks,
Tolga

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


Tolga,

Please allow me to say that now I am totally confused!

You say that IPSP cannot relay SUA traffic. At the same time SGP can "host
local applications" and is the only process that relays according to your
opinion.

What is the difference then between IPSP1-IPSP_with relay-IPSP2 from
SGP1-SGP_with_relay-SGP2 ???

In the latter case SGP1 and ! SGP2 host local applications in the IP domain
and do not! have any access to the calssical SS7 netowork (therefore do
actually behave as an IPSP processes)!

But then we finish at the starting point -> AS/RC concept is originally
desinged for direct-to-direct communications and relay seems not to be
elaborated in the SUA RFC at all (e.g. how should relay behave in the
environment of multiple AS'es/RC'es per signalliong processes etc...)! All
of your answers to my previous questions are based on the assumption that
IPSP cannot relay SUA traffic!

Take your time and please help me to understand SUA Relay! Looking into the
SIGTRAN mail archieve this seems to bother many people.

This relay thing in SUA seems to be totally incompatible with AS/RC concept
which is copy/pasted from the M3UA specification which on the other hand
forbids relay!

kind regards/ Stanislav



Tolga Asveren wrote:
Stanislav,


-----Or! iginal Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Sent: Wednesday, December 14, 2005 4:50 PM
To: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

Thank You very much! ! Now it is clear!

Could You please explicilty confirm or denay with TRUE or FALSE the
following statement:

Once a message comes from SS7 to SUA network it can be relayed only at two
places, namely SGW and ASP but not at IPSP place.
[TOLGA]Actually, if an ASP is capable of relaying messages I would call it
SGP, so I would say only a SGP is capable of relaying messages -please note
that a SGP can host local applications-. It is true that IPSP can't realy
messages.

with very best regards/ Stanislav



Tolga Asveren wrote:
Stanislav,

If the whole SPMC is down (ISUP, SCCP etc..) then you send TFC. Otherwise,
you don't send anything, just mark the user part, which ! is down as
"unavailable". If a mess! age from SS7 network arrives to that user part, you
reply with UPU, no different than with regular SS7 case.

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


Tolga,

You didn't understood my TFP point below -> actually I asked what if SUA
gateway looses connection to SPC in the SUA network, should it send TFP in
the MTP network?

Then you have my objection on how to indicate inaccessiblity of particular
application only (SCCP application in this case at SPC but not ISUP or BICC
at the same SPC)!

Thank You!

kind regards/ stanislav



Tolga Asveren wrote:
Stanislav,


-----Original Message-----
From: Stanislav Ivanovich [mailto:stanislav_ivanovich@...]
Sent: Wednesday, December 14, 2005 4:09 PMTo: Tolga Asveren
Subject: RE: [Sigtran] AS concepts and Relay in SUA and M3UA


Tolga,

SUA RFC:

1.3.1.2. Signalling Gateway as relay-point


"A Glo! bal Title translation is executed at the signalling gateway, before
the destination of the message can be determined. The actual location of the
SCCP-user is irrelevant to the SS7 network. GT Translation yields an "SCCP
entity set", from which an Application Server can be derived. Selection of
the Application Server is based on the SCCP called party address (and
possibly other SS7 parameters
depending on the implementation)."
[TOLGA]Check 1.4.6 as well. 1.3.1.2 is nothing else than the good old GTT.
1.4.6 talsk about the SUA specific relay functionality.

There is no word about SPC based relay in SUA gateway. If you think that SPC
relay in SUA gateway (!) is supposed to relay based on SPC is it supposed to
send TFP when! the SPC is inaccessible (i.e. to behave ! as MTP STP)?
[TOLGA]You should use SUA defined SSNM messages.

If so how you can inidcate inaccessiblity of only SCCP applications by means
of TFP? MTP message TFP indicates inacc! essiblity to all user parts not
just
particular one!

You are saying that IPSP does not contain relay. Are you saying that only
ASP can relay to the final IPSP which cannot relay further?
[TOLGA]An IPSP communicated only with another IPSP. Any other type of
communication requires interworking on application level.

thank You!

/stanislav
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com



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



__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! ! Mail has the best spam protection around
http://mail.yahoo.com



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

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www1.ietf.org/mailman/listinfo/sigtran

[Brian F. G. Bidulock]

Tolga,

SUA has relaying at an IPSP.

--brian

Tolga Asveren wrote:                         (Fri, 16 Dec 2005 13:28:51)
> [TOLGA]Yes, there is no relaying for IPSP, neither for M3UA nor for SUA.

--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/

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

[Brian F. G. Bidulock]

Tolga,

Tolga Asveren wrote:                                                 (Fri, 16 Dec 2005 14:23:33)
> [TOLGA]Do you mean relaying between two local SCCP-Users?

Local and remote.

--brian

--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/

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

[Tolga Asveren]

Hmmm, for remote relaying -which I was referring as "relaying" till now-, I
personally disagree that it is to be supported by SUA IPSP, it is against
the definition of IPSP add such a configuration should be provided by SUA
relaying. I consider SUA relaying equivalent to SUA SG-SG but I don't know
whether everybody will buy that point.

In any case, I believe the thing to do is to define SUA Relaying and SUA
IPSP functionality -at least what they do provide and do not provide-, in a
document. Probably IG is a good place for that(?).

I think, before another long thread starts, it could be a good idea to hear
from the authors of SUA (John) and of SUA IG (Lode) -and from others as
well-, what they have to say about this issue.

    Thanks,
    Tolga

> -----Original Message-----
> From: sigtran-bounces@... [mailto:sigtran-bounces@...]On
> Behalf Of Brian F. G. Bidulock
> Sent: Friday, December 16, 2005 3:19 PM
> To: Tolga Asveren
> Cc: sigtran@...
> Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
>
>
> Tolga,
>
> Tolga Asveren wrote:
>    (Fri, 16 Dec 2005 14:23:33)
> > [TOLGA]Do you mean relaying between two local SCCP-Users?
>
> Local and remote.
>
> --brian
>
> --
> Brian F. G. Bidulock
> bidulock@...
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@...
> https://www1.ietf.org/mailman/listinfo/sigtran
>

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

[Tolga Asveren]

Brian,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock@...]
> Sent: Friday, December 16, 2005 4:09 PM
> To: Tolga Asveren
> Cc: sigtran@...
> Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
>
>
> Tolga,
>
> I am an author of the SUA RFC.

[TOLGA] Yes, you are one of the authors but I think it is clear that neither
the concept of SUA-IPSP nor SUA-relay is clearly defined in the SUA
documents and I believe it would be useful to hear from other people
regarding this issue, before deciding for supplementary text.

>
> --brian
>
> Tolga Asveren wrote:
>                    (Fri, 16 Dec 2005 15:21:18)
> > Hmmm, for remote relaying -which I was referring as "relaying"
> till now-, I
> > personally disagree that it is to be supported by SUA IPSP, it
> is against
> > the definition of IPSP add such a configuration should be
> provided by SUA
> > relaying. I consider SUA relaying equivalent to SUA SG-SG but I
> don't know
> > whether everybody will buy that point.
> >
> > In any case, I believe the thing to do is to define SUA Relaying and SUA
> > IPSP functionality -at least what they do provide and do not
> provide-, in a
> > document. Probably IG is a good place for that(?).
> >
> > I think, before another long thread starts, it could be a good
> idea to hear
> > from the authors of SUA (John) and of SUA IG (Lode) -and from others as
> > well-, what they have to say about this issue.
> >
> >     Thanks,
> >     Tolga
> >
> > > -----Original Message-----
> > > From: sigtran-bounces@... [mailto:sigtran-bounces@...]On
> > > Behalf Of Brian F. G. Bidulock
> > > Sent: Friday, December 16, 2005 3:19 PM
> > > To: Tolga Asveren
> > > Cc: sigtran@...
> > > Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
> > >
> > >
> > > Tolga,
> > >
> > > Tolga Asveren wrote:
> > >    (Fri, 16 Dec 2005 14:23:33)
> > > > [TOLGA]Do you mean relaying between two local SCCP-Users?
> > >
> > > Local and remote.
> > >
> > > --brian
> > >
> > > --
> > > Brian F. G. Bidulock
> > > bidulock@...
> > > http://www.openss7.org/
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > Sigtran@...
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran@...
> > https://www1.ietf.org/mailman/listinfo/sigtran
>
> --
> Brian F. G. Bidulock
> bidulock@...
> http://www.openss7.org/
>

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

[Brian F. G. Bidulock]

Tolga,

I am an author of the SUA RFC.

--brian

Tolga Asveren wrote:                                                                 (Fri, 16 Dec 2005 15:21:18)

> Hmmm, for remote relaying -which I was referring as "relaying" till now-, I
> personally disagree that it is to be supported by SUA IPSP, it is against
> the definition of IPSP add such a configuration should be provided by SUA
> relaying. I consider SUA relaying equivalent to SUA SG-SG but I don't know
> whether everybody will buy that point.
>
> In any case, I believe the thing to do is to define SUA Relaying and SUA
> IPSP functionality -at least what they do provide and do not provide-, in a
> document. Probably IG is a good place for that(?).
>
> I think, before another long thread starts, it could be a good idea to hear
> from the authors of SUA (John) and of SUA IG (Lode) -and from others as
> well-, what they have to say about this issue.
>
>     Thanks,
>     Tolga
>
> > -----Original Message-----
> > From: sigtran-bounces@... [mailto:sigtran-bounces@...]On
> > Behalf Of Brian F. G. Bidulock
> > Sent: Friday, December 16, 2005 3:19 PM
> > To: Tolga Asveren
> > Cc: sigtran@...
> > Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
> >
> >
> > Tolga,
> >
> > Tolga Asveren wrote:
> >    (Fri, 16 Dec 2005 14:23:33)
> > > [TOLGA]Do you mean relaying between two local SCCP-Users?
> >
> > Local and remote.
> >
> > --brian
> >
> > --
> > Brian F. G. Bidulock
> > bidulock@...
> > http://www.openss7.org/
> >
> > _______________________________________________
> > Sigtran mailing list
> > Sigtran@...
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
>
> _______________________________________________
> Sigtran mailing list
> Sigtran@...
> https://www1.ietf.org/mailman/listinfo/sigtran

--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/

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

[Brian F. G. Bidulock]

Tolga,

No supplementary text is necessary.

Read section 1.4.6 Relay function.

Read section 1.5 Internal Function Provided in the SUA Layer.

Read section 1.5.3 Address Mapping Funciton at a Relay Node.

Read section 3.4.1 Destination Unavailable (DUNA).
Read section 3.4.2 Destination Available (DAVA).
Read section 3.4.3 Destination State Audit (DAUD).
Read section 3.4.4 Signalling Congestion (SCON).

Read section 3.10.9 ASP Capabilities.

I think that it is quite clear that DAUD can be sent to a relay
point (not only an SG), and that a relay point can send DUNA, DAVA
and SCON (not only an SG), and that an IPSP can indicate its
ability to relay with ASP Capabilities.

All contrary to your M3UA perspective.

--brian

Tolga Asveren wrote:                                                 (Fri, 16 Dec 2005 15:55:49)

> Brian,
>
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:bidulock@...]
> > Sent: Friday, December 16, 2005 4:09 PM
> > To: Tolga Asveren
> > Cc: sigtran@...
> > Subject: Re: [Sigtran] AS concepts and Relay in SUA and M3UA
> >
> >
> > Tolga,
> >
> > I am an author of the SUA RFC.
> [TOLGA] Yes, you are one of the authors but I think it is clear that neither
> the concept of SUA-IPSP nor SUA-relay is clearly defined in the SUA
> documents and I believe it would be useful to hear from other people
> regarding this issue, before deciding for supplementary text.

--
Brian F. G. Bidulock
bidulock@...
http://www.openss7.org/

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