Subject: Re: [Sigtran] M3UA - ASP Inactive

From: [email-masked]
Date: Tue, 12 Nov 2002 01:36:41 -0500

---------------------- Forwarded by Jeffrey Craig/Raleigh/TEKELEC on
11/12/2002 01:41 AM ---------------------------

Jeffrey Craig
11/12/2002 01:32 AM

To:    [email-masked]
cc:    [email-masked]

Subject:    Re: [Sigtran] M3UA - ASP Inactive  (Document link: Jeffrey
       Craig)

Hello Brian,

This contradicts the consensus at the plugtest where it was expressed by
several
companies that their ASPs desire to receive SSNM during ASP-INACTIVE. Those
of you who are following the list for M3UA, please express your opinions
now.

My opinion is that SSNMs sent by SG to ASP during ASP-INACTIVE are valid
and
MAY be processed by the ASP.

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 11/11/2002
07:20:51 PM

Please respond to [email-masked]

Sent by:    [email-masked]

To:    "Wung, Joseph" <[email-masked]>
cc:    [email-masked]
Subject:    Re: [Sigtran] M3UA - ASP Inactive

Joseph,,

Wung, Joseph wrote:                      (Mon, 11 Nov 2002 18:37:28)
> The M3UA RFC stated,
>
> "In this [ASP-INACTIVE] state the ASP SHOULD NOT be sent any
> DATA or SSNM messages for the AS for which the ASP is inactive."
>
> Does anyone have problems with this statement like I do?  I agree
> that the ASP should not be sent with DATA when in this state.
> But, I don't see reasons why SSNM should also be prohibited from
> being sent to the ASP.  In fact, the ASP in this state would like to know
> what has happened in the SS7 network and then update its routing
> information accordingly before turning on user traffic very much like
> MTP restart does.

The proper approach for a restart procedure is for the ASP to
send a DAUD for the AS to update its routing tables, if the ASP
has not already obtained that data from its peers in the AS by
other means (i.e, ASP-ASP communication).  It is a waste
(and possibly a danger) for the SG to send SNMM for all inactive
AS when the AS has no indicated a need for the information.
This was the concensus on the matter captured in the RFC.

>
> I would like to see "SSNM" being taken out from the quote.
> Any objection?

Strong objection.  It was added because the DAUD procedure exists
for a restarting AS to use if it needs it.

--brian

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 12 Nov 2002 02:40:55 -0700

Jeffrey,

This issue was addressed in September 2001 in the thread "M3UA: MTP Restart"
where the restarting behavior of SG MTP and ASP AS was addressed.  This is why

> > DATA or SSNM messages for the AS for which the ASP is inactive."

It was discussed again in December of 2001 in the thread "m3ua 10, sua 9: SSNM
to inactive ASPs" where the end result was the same.  There is no need to send
SSNM to inactive ASPs.  There are a large number of reasons for not doing so.

There is no reason to require an SG to send SSNM to inactive AS and the SG
cannot be required to do so.  The ASP has at its disposal the DAUD procedure
and can obtain an update any time that it likes once it is active, or can skip
the DAUD procedure and rely on the responsive MTP-PAUSE procedures to MTP3
users.  No example could be brought forward where an ASP could get any
advantage whatsoever from receiving SSNM while inactive.

(When an AS is inactive, the SG is not even required to maintain valid routing
information for the AS.  It is only once the AS is active that the SG might
care to send anything to it at all.)

The correct procedure for a restarting ASP (an ASP going ASP-ACTIVE for an AS)
is to perform the DAUD procedure.  You will see in Section 4.6 MTP Restart:

   "When the SG has completed the MTP Restart procedure, the M3UA layers at
   the SGPs inform all concerned ASPs in the ASP-ACTIVE state of any
   available/restricted SS7 destinations using the DAVA/DRST messages."

The intention here was that in non-cluster routed networks with a large number
of signalling points, the amount of signalling information sent after MTP
Restart Ends to an active ASP may be a significant amount of information (long
list of DAVAs), and sending these to an inactive ASP is foolish and further
delays the MTP restart procedure.

So, for the MTP restart procedure, no DAVA/DRST messages are sent to ASPs in
the ASP-INACTIVE state.  Any ASP relying upon SSNM messages to be sent to it
during the ASP-INACTIVE state will not only lose normal SSNM messages but will
lose SNMM messages sent as part of the MTP restart procedure.

Also, the correct procedure for an ASP is described in Section 4.6 as follows:

   "The ASP MAY choose to audit the availability of unavailable destinations
   by sending DAUD messages.  This would be for example the case when an AS
   becomes active at an ASP and does not have current destination statuses."

The phrase "does not have current destination statuses" was intended to
account for the situation where an ASP which is becoming active for an AS
already has valid availability/restriction/congestion information from one of
its ASP peers.

So, everything in the RFC is declares that ASPs should use the DAUD procedure
when the go active for an AS if they don't have current routing information
and that SSNM will not be sent to inactive ASPs, neither during the normal
course of affairs, nor during MTP restart.  These passages received careful
attention, much discussion and clear consensus before the move to the RFC and
there are no interoperability issues to be addressed.

The ASPs at the plugtest that failed to implement the simple DAUD procedure as
described in section 4.6 still do not have a interoperability problem: they
can assume when they go active that all destinations are available and rely on
the fact that the SG will send a responsive DUNA/SCON message for every
unavailable or congested destination to which the AS attempts to send.  So the
ASP can discover very quickly the same information that would be relayed in
response to a DAUD by simply sending traffic.  There is no need for ASPs to
collect SSNM in the inactive state (even less work for the implementer).

It should be pointed out that even the SG's view of the SS7 network will be
out of sync with actual conditions when signalling traffic management messages
are lost or delayed in the network.  In those instances, it is only the fact
that the SS7 network itself implements responsive procedures that the ASP will
be informed of the ultimate state of each destination.

There was also the problem of dynamic registration with regard to SSNM.  This
problem is as follows: the ASP does not have a "de-registered" state for an AS,
it only has active and inactive states for an AS.  An ASP is inactive for an
AS even when it has not yet registered for the AS.  Considering that there is
no requirement on an SG to hand out the same RC value for each cycle of
registration/deregistration of an ASP for a particular AS, the SG might not
have an RC value assigned to an ASP which is in the ASP-INACTIVE state for an
AS.  It can hardly send SSNM to it then.

Overall the reasons for not sending SSNM to ASPs in the inactive state
outweigh any misunderstood advantage and this is why the RFC says SHOULD NOT.
An that is where the RFC should remain.

--brian

[email-masked] wrote:                 (Tue, 12 Nov 2002 01:36:41)