Subject: RE: [Sigtran] ASP Capabilities value 0x2 of interworking field

From: [email-masked]
Date: Mon, 19 Dec 2005 16:10:52 +0200

Tolga,

>[TOLGA]I want to emphasize the difference between "node" and 
>"process". A SIGTRAN node may act as different process types 
>but from SUA point of view those are different entities. There 
>is no doubt that one can have different process types in a 
>signle node. In the light of this, are you saying that SUA is 
>"process-type agnostic" because any type of functionality can 
>be provided by any process type? Then, why do we have 
>different process types?

I think that, for an implementation - an implementation can
support SGP, ISPS or relay node.  The notion of a process,
IMO, is an implementation issue - different OSes may behave
different.  A ISPS that supports relaying needs to indicate
that support, as not all ISPS will support relaying.  

At least in writing the RFC, I assumed 'process' not to have
a normative value, but to try to capture the overall functionality
in a descriptive manner.

Do you feel that we need to be more precise about this?  I don't
think that the 'process' has normative value in most RFCs.

thanks,
John

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 19 Dec 2005 10:29:48 -0500

John,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 19, 2005 9:11 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] ASP Capabilities value 0x2 of interworking field
>
>
> Tolga,
>
[TOLGA]Just to make it more clear what I mean regarding this issue:
I use the word "process" in SIGTRAN sense, e.g. the "P" in ASP, SGP etc..
>From SIGTRAN point of view, it corresponds to a state machine/procedures for
the corresponding "process type".

If a SIGTRAN node wants to support both IPSP and relay functionalities, my
understanding till now was:

 +--------------------+
 |  +--------------+  |
 |  |  App. Logic  |  |
 |  +-----+--+-----+  | SUA-node with
 |  | SGP |  |IPSP |  | IPSP and SGP
 |  +-----+  +-----+  | capability
 +--------------------+

Physically, one can implement SGP and IPSP in a single "process" -process
used in OS terms here-, but this is really besides the point in terms of
functionality described in specifications.
> a normative value, but to try to capture the overall functionality
[TOLGA]Yes, I agree with your that view. Now, if we revisit the main
functionalities
a)Relaying
b)Hosting applications
c)Interfacing with conventional SS7 networks (Actually this probably is
irrelevant in terms of SUA, why should I care whether a peer interfaces with
convetional SS7, what matters is only whether I should send messages for a
specific destination to that peer or not)

I believe it is clear that b) is supported by all process types, i.e. ASP,
SGP and IPSP

For a), it is obvious that SGP supports it. ASP seem supporting it. In that
case, what is the difference between SGP and ASP from provided functionality
point of view? Why not call both of them SGP?

If IPSP is supporting a), what is the difference between IPSP and SGP or
ASP?Much more importantly than that, if one considers that IPSP is a direct
relationship between 2 applications, how can one justify the concept of
SUA-level relay for IPSP, this would mean that one does not have a direct
connection between applications and why one shouldn't use ASP-SGP-ASP
configuration(first figure below)? Shouldn't relay be performed on
application layer, if such a need exists for IPSP case(second figure below)?

(I use ASP/IPSP to refer to the corresponding M3UA stack instances in the
figures below)

  +-------+                 +-------+
  | App1  |                 | App2  |
  +-------+                 +-------+
  | ASP1  |                 | ASP2  |
  +---+---+                 +---+---+
      |                         |
      |                         |
      |       +------+          |
      +-------+ SGP1 +----------+
              +------+
1- Relaying on SGP1

 +-----+       +-----+        +-----+
 |App1 |       |App2 |        |App3 |
 +-----+       +-----+        +-----+
 |IPSP1+-------+IPSP2+--------+IPSP3|
 +-----+       +-----+        +-----+
2- Relaying on App2 (not in IPSP2 M3UA stack)

AFAICS, asking IPSP2 M3UA stack to perform relaying is to push application
layer functionality to M3UA stack (it will be M3UA stack which decides when
to activate/deactivate RKs, the correlation/coupling between different As
etc...)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Dec 2005 12:24:24 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Mon, 19 Dec 2005 10:29:48)

--X--snip--X--
> specific destination to that peer or not)

Yes it matters.  Take some time to understand SUA before making such broad
statements.  SUA specifies interworking fields in the Called Party Address
that specifically control the mapping of the address into SS7 fields for
interworking with SS7 networks.

> I believe it is clear that b) is supported by all process types, i.e. ASP,

No, not all SUA SGPs host applications.  Just as not all STPs support SCCP users.

> point of view? Why not call both of them SGP?

No, not all SUA SGPs support relaying.  Just as not all STPs act as an SCCP relay.

The SUA SGP, by definition, does c), interfacing with conventional SS7 newtorks.

> application layer, if such a need exists for IPSP case(second figure below)?

You are still thinking MTP.  Consider that you have an all-IP network with
not SS7 network interworking from the perspective of SCCP and SUA:  Where
are you going to place your GTT so that you can administrate your network?

Your first diagram would restrict GTT to be located at a node supporting SS7
network interworking, the SGP.  In an all-IP network there is no need for an
SGP, so that configuration is too restrictive.

In your second diagram, SCCP GTT is performed by SCCP or in the all-IP case
the SUA layer relay function.  No SCCP-User performs this function and it is
not possible to have the "application" or SUA-User perform the relay function.
(The interface lacks the primitives.)  Therefore, requiring an application to
do the relaying at IPSP2 is too restrictive.

What SUA does is permit the relaying capability to be added to any node in
the network (including ASP2 in your diagram below), allowing flexible placement
of the GTT function within the SUA network.

> (I use ASP/IPSP to refer to the corresponding M3UA stack instances in the

Well, no, it is the same story for the "Transfer Function" as it is for
"SCCP Relay".  It would be a simple matter to add ASP Capabilities to M3UA
and permit transfer nodes to send SNMM.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 19 Dec 2005 15:08:36 -0500

Brian,

-just replying your comments, which matter-

[..snip..]
> No, not all SUA SGPs host applications.  Just as not all STPs
[TOLGA]The point is that they *CAN*, and I think you agree with this. I am
not saying that all SUA entities MUST host local applications but they are
able to do so.
> No, not all SUA SGPs support relaying.  Just as not all STPs act
[TOLGA]Again the point is that they are able to do so based on the
specification.
> are you going to place your GTT so that you can administrate your network?
[TOLGA]SGPs.
> SGP, so that configuration is too restrictive.
[TOLGA]A SGP does not need to have SS7 interface. You put it there, if you
need to acces conventional SS7 network.
> of the GTT function within the SUA network.
[TOLGA]I am not sure that it is just GTT based routing. It seems that 1.4.6
is speaking of pure PC+SSN based relaying as well -where a node receives a
message with destination address PC+SSN and relays it-.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Dec 2005 19:13:53 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Mon, 19 Dec 2005 15:08:36)
> not saying that all SUA entities MUST host local applications but they are
Theoretically maybe, in practice they don't.

> [TOLGA]Again the point is that they are able to do so based on the
Again, in practice they don't.  SCCP relay points are normally interior
to a network, not at the edge.

> > are you going to place your GTT so that you can administrate your network?
Placing GTT at the edge of the network is not practical.

> need to acces conventional SS7 network.
So in M3UA what is an SGP with no SS7 interface?  An IPSP that supports
relaying?

> message with destination address PC+SSN and relays it-.

That's why we called it AMF instead of GTT.  But AMF serves the same role as
GTT and GTT can in fact be the implementation of the AMF.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 20 Dec 2005 08:46:56 -0500

Brian,

[..snip..]
> Placing GTT at the edge of the network is not practical.
[TOLGA]At least we agree that SUA SG can act as relay. I disagree with you
that you consider SG at the edge of the network. This is not mandatory by
protocol. You can have them whereever you want and with relaying support
they perform what you want to achieve: allowing easier management of the
network. That is the idea why there is relaying support defined for SGs.
> So in M3UA what is an SGP with no SS7 interface?  An IPSP that supports
[TOLGA]No, still an SG. IPSP is a direct, peer-to-peer relationship between
two applications. SG-SG is a peer-to-peer relationship between two relaying
agents. Whether they relay to a node in conventional SS7 network, to another
IP entity or to a local application is conceptually not important.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 07:25:07 -0700

Tolga,

Tolga Asveren wrote:                                                 (Tue, 20 Dec 2005 08:46:56)
> network. That is the idea why there is relaying support defined for SGs.

Interconnect is not done at the core of the network.  GTT is.  No self
respecting SS7 network operator would connect your SUA junk to their
primary STPs any day soon.  Lot's o' luck.

> IP entity or to a local application is conceptually not important.

SUA already has this concept.  Any element can be a relay within the IP or
SS7 domains.

Only M3UA needs the SG-SG concept because currently only an SG can relay, and
now only within the SS7 domain.

For M3UA, however, providing relay within the IP domain is pointless.  Each
originator knows the address of the final destination and might as well form
an association with and send it there directly.  M3UA relays accomplish nothing
more than an IP router already aptly acheives.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 20 Dec 2005 09:18:44 -0500

Brian,

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, December 20, 2005 9:25 AM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Sigtran] ASP Capabilities value 0x2 of interworking field
>
>
> Tolga,
>
> Tolga Asveren wrote:
[TOLGA]I think you also agree that there is a need to organize networks
hierachicaly and for that reason we need relaying. That hierarchical
organization can depoend on different SS7 constructs depending on the needs
of the operator, e.g. GTT, and entities supporting relay can be deployed
anywhere in the network again depending on the needs.
> more than an IP router already aptly acheives.
[TOLGA]I disagree with you. It allows hierarchical organization/easier
configuration of the network and also backhauling SS7 traffic over IP. If
you look to other IP based protocols, which are supposed to be used between
core network entities, you will see similar capabilities as well, e.g.
Diameter. Probably, I should quote one of your favorites: "If you don't want
it, do not use it"

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 07:44:34 -0700

Tolga,

Tolga Asveren wrote:                                                 (Tue, 20 Dec 2005 09:18:44)

> anywhere in the network again depending on the needs.

And so SUA permits any node to have the relay capability in the IP domain.

> Diameter. Probably, I should quote one of your favorites: "If you don't want

STPs act a link concentrators.  When there are no links, there is no need
for concentration.  MTP relay in the IP domain is pointless.

SG-SG is more important for a usable IPSP for M3UA.

SUA is fine as it is.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 20 Dec 2005 09:51:14 -0500

Brian,

> And so SUA permits any node to have the relay capability in the IP domain.
[TOLGA]I don't see how this can happen just by definition of IPSP or why we
should use IPSP by communicating with a node, which is relaying messages. In
any case, I think this is an architectural issue, which needs to be
discussed/clarified throughly.
> for concentration.  MTP relay in the IP domain is pointless.
[TOLGA]I again have to disagree with you. STPs do perform more than just
link concentration, e.g. message routing. In IP domain, if you have direct
connections between each entity, any change in the configuration could
effect the whole network, and most people wouldn't like this at all. By
centralizing certain routing decisions, one can limit necessary changes to
those centralized entities. Furthermore, one could like to have relay to
backhaul SS7 traffic over IP or to have a single interface between different
administrative domains where some screening based on SS7 constructs could be
performed. As I indicated before, relay is a common concept for IP-based
protocols as well, if they are going to be used between core network
enitites.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 08:24:48 -0700

Tolga,

Tolga Asveren wrote:                                                 (Tue, 20 Dec 2005 09:51:14)
> discussed/clarified throughly.

Not an issue at all.  Any node in the SS7 network can be an SCCP relay point
as well.

> protocols as well, if they are going to be used between core network

For M3UA relaying in the IP domain, use BGCP, firewalling, NAT, other
middlebxes, at the routers.  You don't need to fabricate the concept of
an SS7 router (STP) in the IP network to perform its functions.  Those
functions are already performed by IP.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 20 Dec 2005 10:15:15 -0500

Brian,

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, December 20, 2005 10:25 AM
> To: Tolga Asveren
> Cc: [email-masked]
[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.
> functions are already performed by IP.
[TOLGA]People usually want/need to perform the organization/security checks
based on the constructs of the protocol, which is payload from IP point of
view, e.g. SS7 constructs, hence there is the need to have entities working
on application layer from IP point of view. In any case, this is really
besides the point for this thread.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 08:43:45 -0700

Tolga,

Tolga Asveren wrote:                                                 (Tue, 20 Dec 2005 10:15:15)
> those different functionalites should reside.

Functional placement is an implementation issue.

> besides the point for this thread.

The MTP GWS function does nothing more than an IP firewall.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Stanislav Ivanovich <[email-masked]>
Date: Tue, 20 Dec 2005 07:44:05 -0800 (PST)

Hello,
   
  I fully agree with Tolga.
   
  Although Brian says:   
  "For M3UA relaying in the IP domain, use BGCP, firewalling, NAT, other
middlebxes, at the routers. You don't need to fabricate the concept of
an SS7 router (STP) in the IP network to perform its functions. Those
functions are already performed by IP."

  SUA RFC still does provide possiblity to relay on PC+SSN (i.e. not only GT)!?! Therefore I do not understand his point here!

  However, I think that we all agree that we need relay in xxUA networks (be that M3UA or SUA). I think that no one is questioning that.
   
  However the essential point is that the AS/RC concepts which is symmetrical one (at least in SE model) is not suitable to perform the relay.
   
  Traditional SS7 networks (MTP and SCCP) are asymmetrical in sense that they do not care where the message originated but where it has to be delivered.
   
  In xxUA networks AS/RC concept in mandatory SE model both originating and destination addresses have to be specified and only these combinations are allowed. This is extremely unfriendly for relay!
   
  Thus in traditional networks TFP or SSP messages manage traffic in only one direction. Even more granularity of traffic is uniquely and defined by the specifications.
   
  However in the AS/RC concept in the mandatory SE model one ASP TM message manages traffic in both directions!
   
  SUA RFC:
   
  "4.3.4.3. ASP Active Procedures
  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."
   
  In another words it is not only important what is the state of the remote destination where the message goes but also state of the AS the ASP participates in!

  Even more traffic granularity in traditional SS7 networks is fixed between all the relay points! Thus you have so called "SPC destination", "User Parts", "SCCP Subsystems" which are on the external protocol represented with "SPC", "SI", "SSN" and these are used by all the relay points.
   
  However in xxUA networks AS/RC concept causes that tzraffic granularity is not fixed by agreement of two adjacent relay points. In another words traffic granularity is defined by AS/RC between the relay points! How do you manage this traffic???

  Even more, essential point is that the AS/RC is a redundancy concept. In IPSP-IPSP communication it is application logic (not xxUA layer logic!) which selects and/or loadshares between different ASP/IPSP'es. This logic also uses RC to point to a particular application the remote process serves.
   
  However if you use the AS/RC concept as a choice to build you relay network then you take control from the applications to point to RC. The applications then do not control RC'es thus do not have control over the essential/core meaning of the AS/RC concept. In that case IPSP'es points with SCCP GT relay functionality choose RC value! For this reason I say that RC is pointless there. What do you think it is good for??? Please, give us just one example.

  regards/ Stanislav Ivanovich

"Brian F. G. Bidulock" <[email-masked]> wrote:  Tolga,

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 08:59:09 -0700

Stanislav,

Stanislav Ivanovich wrote:                                       (Tue, 20 Dec 2005 07:44:05)
> 
> 
>    However  the  essential  point  is  that  the  AS/RC concepts which is
>    symmetrical  one (at least in SE model) is not suitable to perform the
>    relay.
> 
>    Traditi!  onal  SS7  networks (MTP and SCCP) are asymmetrical in sense
>    that they do not care where the message originated but where it has to
>    be delivered.

Yah. SS7 links are uni-directional.

> 
>    In  xxUA networks AS/RC concept in mandatory SE model both originating
>    and   destination   addresses   have   to   be   specified   and  only
>    these combinations  are  allowed.  This  is  extremely  unfriendly for
>    relay!

No they don't.  Any routing key is possible.  Dynamic registration does not
support all possible routing keys.  Provisioned routing keys can take any
form.  Also note that SUA registration supports multiple and ranges of
addresses in a dynamically registered routing key.  Not even M3UA restricts
its routing keys to a single originating or destination point code.  You
can have one destination HLR point code and 400 MSC originating point codes
if you'd like.  Or visa versa.  Or 400 of each.

> 
>    Thus  in  traditional  networks  TFP or SSP messages manage traffic in
>    only  one  direction. Even more granularity of traffic is uniquely and
>    defined by the specifications.
> 
>    However  in  the  AS/RC  concept  in the mandatory SE model one ASP TM
>    message manages traffic in both directions!

ASP TM messages are not used to manage relay.  SNMM messages are.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Stanislav Ivanovich <[email-masked]>
Date: Tue, 20 Dec 2005 08:15:01 -0800 (PST)

Brian,
   
  I think you didn't understand my point, and as I see you again avoid to answer the essential question here -> what is the AS/RC cocnept used for in between two relay points which perform relay not on application logic but instead on SCCP logic (and even MTP logic since SPC relay is also possible in SUA)?
   
  [Brian]

  Why do you then neeed ASP Traffic Managemnt messages for different RC'es in between two relay points in SUA if you claim that they do not manage traffic but instead only SSNM.
   
  Are you saying that ASP TM messages are not used in between two relay points?
   
  What are they used for, then???

  I must copy my essential point which you constantly avoid:

   
   
  Regarding the SPC point below I am not saying that you cannot use ranges, I am aware of that and I amo not questioning that! I also didn't mention dynamic registration procedure so I do not understand what are you talking about.
   
  My point is -> in SE model one has to specify both orginating address(es) (or ranges) and destination address(es) (or ranges) and only these SS7 relations are possible.
   
  For example, A:SPC=2-100<->B:SPC2-200. 
   In direction A->B it is not allowed to send 2-900 -> 2-200 but only 2-100 -> 2-200. In the opposite direction it is not allowed to send 2-200 -> 2-600 but only 2-200 -> 2-100. 
   
  In traditional SS7 networks one specify Route Set by only considering remote destination. When you route messages you also consider only state of the remote destinations. But in xxUA networks you must also consider you own state in a specific AS!
  Thus is extremely relay-unfriendly! 
   
  /stanislav

"Brian F. G. Bidulock" <[email-masked]> wrote:
  Stanislav,

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 20 Dec 2005 11:04:36 -0500

[..snip..]
> 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.

---

From: Stanislav Ivanovich <[email-masked]>
Date: Tue, 20 Dec 2005 08:43:57 -0800 (PST)

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 <[email-masked]> wrote:
  
[..snip..]

+-------+
| App4 |
+-------+

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 20 Dec 2005 12:09:07 -0500

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-masked] [mailto:[email-masked]]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

[..snip..]
> > both relay and use IPSP communication. What we are discussing ! is,
where

 +-------+
 | App4  |
 +-------+

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.

---

From: Stanislav Ivanovich <[email-masked]>
Date: Tue, 20 Dec 2005 10:22:59 -0800 (PST)

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

-----Original Message-----

Tolga,

/stanislav

Tolga Asveren wrote:

[..snip..]
where

+-------+
| App4 |
+-------+

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 11:51:19 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Tue, 20 Dec 2005 11:04:36)
>  +-------+ procedures  SGP/ASP

There is no different on the wire between SE IPSP and ASP/SGP with or without
relay as regards ASPSM and ASPTM messages.

The only difference on the wire for Relay is SNMM messages.  (A relay can send
them even if you view it as an ASP or IPSP.)

Diffences not perceivable from the wire are implementation details.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 11:56:02 -0700

Stanislav,

Stanislav Ivanovich wrote:                                                       (Tue, 20 Dec 2005 10:22:59)
> 
>    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 commun!
>    ication  model  between  SGP-SGP since AS/RC concept is not to be used
>    there.

SGs, by definition in the consensus model, have SS7 interfaces.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 20 Dec 2005 13:45:29 -0500

Brian,

> Sent: Tuesday, December 20, 2005 1:51 PM
> To: Tolga Asveren
> Cc: [email-masked]
>                    (Tue, 20 Dec 2005 11:04:36)
> >
> >  +-------+
> >  | App4  |
> >  +-------+
[TOLGA]O.K., finally we are at the root cause of the disagreement. You think
that SE-IPSP and SGP/ASP procedures are the same, I think the opposite.
SGP/ASP is a client/server relationship, where SGP hosts the SCCP logic for
the application on ASP, IPSP/IPSP is a direct, peer-to-peer relationship
between two applications.

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 20 Dec 2005 13:57:38 -0500

Brian,

> Sent: Tuesday, December 20, 2005 1:56 PM
> To: Stanislav Ivanovich
> Cc: SIGTRAN
[TOLGA]I have a different opinion here. It is obvious that the initial/main
purpose was to interface conventional SS7 networks -hence the "gateway" in
the name-, but OTOH conceptually what SGP provides is just hosting
corresponding SCCP(MTP3 for M3UA) layer for the applications on ASPs. As far
as I can see it really doesn't matter whether TDM based links or IP
transport is used to transfer bits and bytes.

You know that it has been agreed that the following, where SGP1 relays
between ASP1 and ASP2 is a valid configuration:

+------+       +------+
| ASP1 |       | ASP2 |
+--+---+       +---+--+
   |               |
   |    +------+   |
   +----+SGP1  +---+
        +------+
Actually, something more important than whether me,you or somebody else
thinks that it is valid is whether the protocol supports it. From SGP point
of view, conceptually it is irrelevant whether the destination is in IP
domain or in conventional SS7 domain.

---

From: Stanislav Ivanovich <[email-masked]>
Date: Tue, 20 Dec 2005 12:14:21 -0800 (PST)

Hello,
   
  I fully agree with Tolga on these fundamental views on the AS/RC concepts and his view on the SUA relay.
   
  On the other hand acceptance of the Brian's view on this issue (AS/RC concepts in SUA relay) ultimately leads to the disappearance of the conceptual difference between the different signaling process types.
   
  What we heard today from Brian is that any process can do anything, namely ASP, IPSP, SGP can all do gateway, relay host applications - and at the same time we have different procedures and process types copy/pasted form M3UA etc...
   
  We also heard from SUA people that definition of processes is Operating System matter (!?!) so there is no need to define/clarify ASP/IPSP/SGP...

  I would like to see/know what is the official procedure in IETF (or SIGTRAN) that is to be called when there are conceptual differences/misunderstandings on some issues between the members. Is there any "voting" here?
   
  / Stanislav

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 18:32:17 -0700

Stanislav,

Stanislav Ivanovich wrote:                                                       (Tue, 20 Dec 2005 12:14:21)
> 
>    What  we  heard  today from Brian is that any process can do anything,
>    namely  ASP,  IPSP,  SGP can all do gateway, relay host applications -
>    and  at  the  same time we have different procedures and process types
>    copy/pasted form M3UA etc...

Again, you  have the cut and paste backward.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 18:29:46 -0700

Tolga,

Go read RFC 2719 again.

--brian

Tolga Asveren wrote:                                                                 (Tue, 20 Dec 2005 13:57:38)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 20 Dec 2005 18:30:57 -0700

Tolga,

Tolga Asveren wrote:                                                                 (Tue, 20 Dec 2005 13:45:29)

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/