Subject: Re: M3UAv8: point code representation

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 14:32:20 -0500

Francois,

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Tue, 21 Aug 2001 16:37:16)
> Brian,
> 
> Thanks for your valuable comments.
> I may have pushed the NIF description a little far to
> illustrate the fact that it could be valid to have message
> transfer in the SS7 AND IP domains in an SG. Moreover, 
> SCCP is not the only User Part liable to be backhauled.
> For example if you need to backhaul TUP or ISUP as well,
> SUA won't do (even if message transfer is only for SCCP).
> 
> Anyway, this discussion is drifting. Initially it started
> by a remark stating that MTP3 required changes to be able
> to transfer messages to both MTP2 and M3UA if the SG had
> transfer functions. There seems to be a convergence to a
> solution where such messages that would be routed to the
> IP domain would be handled by an implementation-specific NIF.
> This could be added as a short description to the draft (#1).

I agree with the statement, but it already apprears in the
draft with respect to the NIF: that the NIF is implementation
dependent and that its specification is out of scope.  Is that
not sufficient?

> 
> Another addition could be:
> Multiple User Parts per PC (on AS) are supported when the
> SG has this STP feature. User Part availability is handled 
> by their peers like in MTP and is not provided by M3UA (#2).

I agree, this should be mentioned in the draft and the role
of DUPU in the direction from AS to SG identified.

> 
> The SSNM and STP features are already described especially in
> 1.4.1 and 1.5.3. However, my point when I mention IPSP in the
> STP scenario was that MTP3 is terminated at the SG for SS7
> perspective, and the AS-SG relation is more of point-to-point
> nature than backhaul. Still, I agree that this is misleading
> because there is no User Part peer on the SG. The text in the
> draft is probably enough as long as everyone realizes what it
> takes to have the STP feature in the SG.
> 
> Francois.
> 

--brian

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

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 21 Aug 2001 22:09:26 -0500

Hi Francois,

[snip]
> ... Moreover, SCCP is not the only User Part liable to be backhauled.
> For example if you need to backhaul TUP or ISUP as well, SUA won't do
> (even if message transfer is only for SCCP).

SUA is still the clear choice where backhaul of both ISUP and SCCP
is concerned where the SG acts as an SCCP relay.  Use M3UA for ISUP
and SUA for SCCP.  The only reason to use M3UA for ISUP is because
there is no ISUA.  If the current NA/RC discussions in M3UA don't
resolve to the concensus AS model of RC in DATA and SNMM, M3UA will
be useless for ISUP anyway.  In that case it would be easier to
carry ISUP using SUA (SSN=-1 CLDT interpreted as M3UA DATA) than
using M3UA.  Nevertheless, if M3UA issues get worked out, the model
which would work is as follows:

        ________                                       ________ 
       |    |   |                                     |   |    |
       | T  |   |                                     |   |  T |
       | C  |   |                                     | I |  C |
       | A  |   |                                     | S |  A |
       | P  | I |                                     | U |  P |
       |____| S |                                     | P |____|
       |    | U |                                     |   |    |
       | S  | P |        ________ _____________       |   |    |
       | C  |   |       |        |             |      |___|    |
       | C  |   |       |  SCCP  |     SUA     |      |   |  S |
       | P  |   |       |        |             |      | M |  U |
       |____|___|       |________|______       |      | 3 |  A |
       |        |       |        |      |      |      | U |    |
       |  MTP3  |       |  MTP3  | M3UA |      |      | A |    |
       |________|       |________|______|______|      |___|____|
       |        |       |        |             |      |        |
       |  MTP2  |       |  MTP2  |     SCTP    |      |  SCTP  |
       |________|       |________|_____________|      |________|
            |                |           |                 |    
            |________________|           |_________________|    

Because it is provided to multiplex SUA and M3UA over the same SCTP
associations by PPI, it is possible to use common SCTP associations.
Here full SCCP transparency including final or non-final GTT or just
MTP-transfer at the SG/STP is provided.  SUA smoothly handles all
issues associated with multiple SGs, handling of segementation/reassembly,
SIF max size interworking, and all the things you need for SCCP,
while M3UA just delivers ISUP.  There are none of the issues of
downwards MTP-User primitives or IPSP operation at the SG for M3UA:
M3UA is the pure backhaul case for ISUP.  If the objective is TCAP
and the connection-oriented procedures are not required, SUA is a
rather trivial extension and shares all of the same ASP management
procedures with M3UA (load 'em once and link 'em to both).

SUA is still far more advisable that trying to push M3UA into
handling the SCCP relay node.  SUA has special provisions (see
thread SUA Relay Problems and the resulting changes to SUA) to
permit multiple SG as either SCCP Relay Nodes or MTP transfers or
both.

The M3UA example is still a bad example.  SUA is far better suited
to providing SCCP Relay Node SGs.

But this has already been discussed in the thread SSN and TID in M3UA.

--brian

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

---