RE: AS concepts and Relay in SUA and M3UA

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 finally 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 <[email protected]> wrote:
  Stanislav,

-----Original Message-----
From: [email protected] [mailto:[email protected]]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 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: [email protected] [mailto:[email protected]]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:[email protected]]
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:[email protected]]
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:[email protected]]
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:[email protected]]
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:[email protected]]
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
[email protected]
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
[email protected]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran