Subject: Re: [Sigtran] M3UA - ASP Inactive

From: [email-masked]
Date: Tue, 12 Nov 2002 13:32:30 -0500

Hello Brian,

Let me more concise:

I recommend that the M3UA text be revised to state that an SG MAY send
SSNMs
to an INACTIVE ASP.

Regards,

Jeff

"Brian F. G. Bidulock" <[email-masked]>@ietf.org on 11/12/2002
04:40:55 AM

Please respond to [email-masked]

Sent by:    [email-masked]

To:    [email-masked]
cc:    [email-masked]
Subject:    Re: [Sigtran] M3UA - ASP Inactive

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
SSNM was added with DATA in the passage:

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

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

--
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 16:23:38 -0700

jeffrey.craig,

[email-masked] wrote:                                           (Tue, 12 Nov 2002 13:32:30)
> SSNMs to an INACTIVE ASP.

Its already does.  SHOULD NOT and MAY are the same thing.

--bria