RE: ASP Capabilities value 0x2 of interworking field

John,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Monday, December 19, 2005 9:11 AM
> To: [email protected]
> Cc: [email protected]
> Subject: RE: [Sigtran] ASP Capabilities value 0x2 of interworking field
>
>
> 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.
[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.
>
> 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.
[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...)

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