Re: Conceptual doubt between an ASP and SGP

Ajay,

Please see comments below...

Ajay Garg wrote:                             (Fri, 14 Mar 2014 11:45:20)
>    I meant that in the scenario all of N1, N2, N3 are pure sigtran-nodes
>    (i.e. no SS7 nodes in the network), is there any usecase when
>    transferring messages from N1->N3 in the configuration ::
>                  * IPSP-IPSP association between N1 <-> N2
>                  * IPSP-IPSP association between N2 <-> N3
>                  * GTT at N2
>    will have ANY different behaviour (from pure end-user point of view)
>    against the configuration ::
>                  * ASP-SGP association between N1 <-> N2
>                  * SGP-ASP association between N2 <-> N3
>                  * GTT at N2

Yes, I understand, however, the former scenario is explicitly not
supported by the M3UA standard (see some clips below).  We explicitly
only supported IPSP in an end-point to end-point connection with no
intermediate transfer function due to the lack of a satisfactory
interworking of SS7 network management functions.

So, for example, in the AS <-> SG <-> AS configuration, the SG
provides management messages to the one AS on the availability,
restriction and congestion state of the routeset toward the other
AS (not to mention the entire gamut of any necessary rerouting
and MTP restart procedures).

IPSP <-> IPSP does not provide any SS7 network management messages
other than perhaps nodal SCON.

In SS7 terminology, consider the IPSP <-> IPSP connection as an
F-link only.  That is, there cannot be an intermediate transfer
function.  IPSP <-> IPSP is really no more than hardwiring a
restricted subset of two MTP-User interfaces together.

It was not necessary for us to reinvent the entire SS7 network
for IPSP mode, as the AS <-> SG <-> AS configuration was
sufficient.

OTOH, SUA does support GTT and transfer at an intermediate IPSP
node, because SCCP defines its own management and can be (and is)
run over other generic network layers (such as SSCOP).  SCCP
also does not restrict the network location of routing functions.

--brian

RFC 4666

1.2 Terminology

   ...

   IP Server Process (IPSP) - A process instance of an IP-based
   application.  An IPSP is essentially the same as an ASP, except that
   it uses M3UA in a point-to-point fashion.  Conceptually, an IPSP does
   not use the services of a Signalling Gateway node.

   ...

1.3.2.  Services Provided by the M3UA Layer

   ...

   The M3UA layer may also be used for point-to-point signalling between
   two IP Server Processes (IPSPs).  In this case, the M3UA layer
   provides the same set of primitives and services at its upper layer
   as the MTP3.  However, in this case the expected MTP3 services are
   not offered remotely from an SGP.  The MTP3 services are provided,
   but the procedures to support these services are a subset of the MTP3
   procedures, due to the simplified point-to-point nature of the IPSP-
   to-IPSP relationship.

   ...

1.4.3.4.  IPSP Considerations

   Since IPSPs use M3UA in a point-to-point fashion, there is no concept
   of routing of messages beyond the remote end.  Therefore, SS7 and
   M3UA interworking is not necessary for this model.

   ...

4.3.  AS and ASP/IPSP State Maintenance

   The M3UA layer on the SGP maintains the state of each remote ASP, in
   each Application Server that the ASP is configured to receive
   traffic, as input to the M3UA message distribution function.
   Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA
   layer in an IPSP maintains the state of remote IPSPs.

   ...

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