RE: ASP Capabilities value 0x2 of interworking field

Tolga,
   
  I agree with you.
   
  I noticed that I made mistake in my qustion addressed to you, I actually meant Appl1<->Appl3 as I correctly assumed.
   
  In addition I would say that any relay based on MTP (SPC) or SCCP (GT) logic should always be covered with SGP<->SGP communication model without having AS/RC concept used in between. In other words I see SG-SG model good regardless is it for GT based or SPC based or anything other...
   
  When I looked into your SGP-SGP draft I forgot to propose maybe change of terminology -> maybe other SIGTRAN community memebers are confused and think that in this way it is relay "on the network edges" or that it assumes "gateway functionality". Actually in the essence it is about new role of the exisitng SGP process whihc is to relay not only between SS7 and IP but also IP to IP. This also implies new communication model between SGP-SGP since AS/RC concept is not to be used there.
   
  Therefore I would rather use name RP (Relay Process) which can be equipped with two independent relay functionalies:
   
  1) Gateway (SS7<->IP)
  2) IP relay (IP<->IP)
   
  Maybe SIGTRAN community will react more freindly towards this concpet if we accept new terminolgy.
   
   
  Anyway I am still waiting to hear from Brian the answer to the fundamental question -> what is the AS/RC cocnept used for in between two relay points? Please see my last mail addressed to Brian.
   
  kind regards/ Stanislav
   
  

Tolga Asveren <[email protected]> wrote:
  Stanislav,

Just because I will need them for the discussion, I will use the following
terms:

direct forwarding: An entity receives a message and has direct connection to
the destination of the message, so it sends the message to the destination

relaying: An entity receives a message and does not have direct connection
to the destination entity, so sends message to another entity, which may or
may not have a direct connection to the final destination

In the figure, there is no relaying relationship as defined above -probably
I should have put one to cover all cases-.

What I think is as follows:
- When there is direct forwarding between two entities, it is a
client/server relationship, e.g. SGP/ASP. this conceptually is the same as
the vanilla SGP/ASP relationship, where SGP provides SS7 interfacing for
ASP. Actually for SUA, GTT makes SGP/ASP relationship a bit complicated due
to its unidirectional nature, maybe for GTT, one should always go with
relaying approach rather than direct forwarding.
- When there is relaying relationship between two entities, it is a
peer-to-peer relationship on message routing level. I call this SG-SG and as
far as I understand, SUA-relay falls into this category (there is no example
for that in the figure).
- When there is direct and peer-to-peer communication between two
applications, it is an IPSP/IPSP relationship.

Now if I try to answer your question considering the above (although you
refer to App1/App2 I believe you actually mean App1/App3 -between App1/App2
there is direct communication and RC/AS concept is used):
App1/App3 communciation requires GTT. If the need were PC+SSN based
relaying, I would think that the relationship between App1 and forwarding
entity should be SGP/ASP interface, i.e. should utilize RC/AS concept -pleae
note that the forwarding entity has direct connections to both of the
applications-. For GTT, I am not sure. I tend to think, it would be better
to have App1/Forwarding entity interface SG-SG, because GTT itself is
unidirectional. Maybe the best is to use always SG-SG, if there is need for
GTT or any other type of relaying. I am really not sure on that point yet,
OTOH I personally firmly believe that this interface definitly shouldn't be
IPSP/IPSP.


Tolga




-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Stanislav Ivanovich
Sent: Tuesday, December 20, 2005 11:44 AM
To: SIGTRAN
Subject: RE: [Sigtran] ASP Capabilities value 0x2 of interworking field


Tolga,

Are you saying that the AS/RC concept should apply in between SUA at appl1
place and SUA relay point in between appl1 and appl2?

/stanislav



Tolga Asveren wrote:

[..snip..]
> > [TOLGA]What about in IP domain? The goal with the protocols is
> to define a
> > sound architecture, which allows interoperability and does not
> allow room
> > for ambiguity. IMO allowing IPSP functionality to allow
> relaying is against
> > those principles. I also want to reemphasize that here we are
> speaking of
> > different roles played by SUA stack, i.e. we can have SUA-node which can
> > both relay and use IPSP communication. What we are discussing ! is,
where
> > those different functionalites should reside.
>
> Functional placement is an implementation issue.
To clarify what I mean, consider the following figure (SUA stands for SUA
functionalities, it does not refer to any specific implementation, e.g. it
can be one or more than one stack instance)

+-------+
| App4 |
+-------+
| SUA + +-------+ +-------+
+--+----+ | App1 | | App2 |
| SGP/ASP +-------+ +-------+
+--procedures-----+ SUA +---IPSP-------+ SUA |
+--------+--+----+ procedures +-------+
| |
SGP/ASP |
+-------+ procedures SGP/ASP
| App5 | | procedures
+-------+ | |
| SUA +---+ | +-------+
+-------+ | | App3 |
+--+----+ +-------+
| SUA +---SGP/ASP----+ SUA |
+-------+ procedures +-------+

Let's suppose for App1/App2 communication, there is no need for GTT -nor for
any other type of relay-, so IPSP procedures are used.

For App1/App3 communication we need GTT, so! messages are sent from App1 to
an entity which can perform GTT and relay. For that communication SGP/ASP
procedures are used.

Let's suppose the node hosting App1 performs certain GTT functions as well
and they are used for communication between App4/App5. In this case, again
SGP/ASP procedures will be used.

This, IMO allows a clean separation between interfaces used for different
purposes.



_______________________________________________
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