Subject: [Sigtran] M3UA - NIF doubts

From: David Santos <[email-masked]>
Date: Fri, 11 Nov 2005 16:52:01 +0100 (CET)

Hi,

I have some doubts about how to implement the NIF:

a) Can the NIF be implemented as a level 4 user part?
b) Should the MTP stack be modified to make the
routing function send messages to the NIF?
c) Can all incoming traffic be sent to the NIF, or
could a SG act as a STP, just  routing messages within
the SS7 network?
d) When a M3UA node is inaccessible, should the SG
send signalling network management messages to the SS7
network (e.g. TFA or TFP) via NIF?

Thanks!

______________________________________________ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 12 Nov 2005 02:08:14 -0700

David,

David Santos wrote:                   (Fri, 11 Nov 2005 16:52:01)
> a) Can the NIF be implemented as a level 4 user part?

Although it is implementation specific, it was our intention that it
should be possible that the NIF could be implemented as one (or more)
rather normal MTP-User(s).

> routing function send messages to the NIF?

If the NIF is implemented as normal MTP-User(s), it should not be
necessary to modify the MTP stack.

> could a SG act as a STP, just  routing messages within

Yes an SG can optionally act as an SEP or an STP.  The multiple SG as
STP scenario is supported by M3UA and looks like the following:

                 |
   SS7                          IP
   Network       |              Network
             _______________                _______     ____
            |    |   _______|        ______|       |   /    \
            |       |       |_______|  ____|  ASP  |  |      |
 B/D-Links  |    |  |  SGP  |________  |   |_______|  |      |
 ___________| STP SG|_______|        | |    _______   |      |
           /|    |  |       |__   +  | | __|       |  |  AS  |
          / |       |  SGP  |__   +  | | __|  ASP  |  |      |
   \     /  |    |  |_______|     +  | |   |_______|  |      |
    \   /   |_______________|        | |    _______   |      |
     \ / C-   |                   +  | | __|       |   \____/
      X  Links|  |                +  | | __|  ASP  |    ____
     / \     _|_____________      +  | |   |_______|   /    \
    /   \   |    |   _______|        | |    _______   |      |
   /     \  |       |       |__   +  | | __|       |  |      |
          \ |    |  |  SGP  |__   +  | | __|  ASP  |  |      |
 __________\| STP SG|_______|     +  | |   |_______|  |  AS  |
            |    |  |       |________|_|    _______   |      |
            |       |  SGP  |_______ |_____|       |  |      |
            |    |  |_______|       |______|  ASP  |  |      |
            |_______________| SCTP         |_______|   \___ /
                 |            Associations

                 |

     Figure 1.  Example (A) Sample Multiple-SG Configuration

In the multiple SG as STP scenrio it is more difficult to implement the
NIF as a normal MTP-User at the SG, particularly considering the use of
DRST in the SG->ASP direction.  (There is no MTP/MTP-User primitive for
DRST.)

Also, it might not be possible to define a local MTP-User at an STP that
can also be reached over an alternate SS7 route (i.e.  C-links).  The
closest analogy would be an SCCP Alias that exists both locally within
the STP as well as existing remotely at the associated STP in the STP
pair.  As many STPs implement this SCCP Alias concept to support ANSI,
providing a similar point code for an ASP might not be possible with a
simple local MTP-User, or it might be.

With no doubt, the NIF is easier to implement for an SG as SEP than for
an SG as STP.

> network (e.g. TFA or TFP) via NIF?

If you think of the AS as an MTP-User, following the NIF as MTP-User (or
even "Alias" MTP-User) approach, when the AS is unavailable, the NIF
could signal uavailability of the MTP-User to the MTP in the same
fashion as it normally does for MTP-Users.

If the MTP stack does not support the same scope of MTP-SAP as is
supported to an AS (e.g, it only supports entire PC MTP-SAPs, or say,
only supports PC-SI MTP-SAPs) then the NIF has some more work to do
correlating the availability of individual AS into a single MTP-SAP, or
correlating the availability of a single AS into multiple MTP-SAPs, to
present a proper SS7 network view.

If the MTP stack supports MTP-SAPs on the same basis or scope as M3UA
Routing Keys, then it is a simpler matter of locally attaching or
detaching the corresponding MTP-User from its MTP-SAP.

Using these approaches it is, IMHO, easier to meet the conformance
requirements on the MTP stack because the MTP stack's conformance to the
SS7 network remains unmodified.  That is, the response of the MTP stack
to AS availability is the same as it would be if the MTP-User at the
local MTP-SAP detaches or attaches and the MTP stack can be relied upon
to do the right thing with regard to the SS7 network.

How an MTP-User attaches or detaches is of course a local implementation
matter for the SS7 stack, however most stacks provide some local
mechanism for doing so.  Some stacks might even provide the ability to
attach or detach to an "SCCP Alias" type point code or PC-SI
combination, that would ease integration of NIF to SG as STP.

I hope that helps.  I can walk through some more specific examples if
you would like.

--brian

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