RE: [Sigtran] M3UA - ASP Inactive

[Tolga Asveren <[e-mail]>]

Joe,

I agree with some of what you are saying, but it is really hard to decide,
what is the "correct" behavior. For example, what is the counterpart of ASP
switching to INACTIVE state in regular SS7 case?Unavailability of user part,
or something else? And what should be done in such a case. The only somehow
related thing I could find in Q.704 is 11.2.7.6
"When the Message Transfer Part is again able to distribute received
messages to a previously unavailable local User Part (local User Part
availability is an implementation dependent notion), the Message Transfer
Part delivers the received messages to that user."

Furthermore, one could argue that if really a smooth transition is
necessary, one should use loadsharing traffic mode instead of active/standby
mode. Another comment could be, a distribution of user parts will be most
probably the case in any situation and user parts will keep status for
destinations, i.e. availability information will be preserved during
switching even for active/standby case.

    Tolga



> -----Original Message-----
> From: Wung, Joseph [mailto:[e-mail]]
> Sent: Tuesday, November 12, 2002 11:39 AM
> To: Tolga Asveren; '[e-mail]'
> Subject: RE: [Sigtran] M3UA - ASP Inactive
> 
> 
> Tolga,
> 
> But this is not about MTP restart.  This is about MTP in the SG
> remains unchanged, and about switchover from one ASP to another.  
> One would want the newly active ASP take over traffic seamlessly
> from where the preivously active ASP has left off without the
> true MTP user knowing there was a switchover.
> 
> Joe 
> 
> -----Original Message-----
> From: Tolga Asveren [mailto:[e-mail]]
> Sent: Tuesday, November 12, 2002 11:23 AM
> To: '[e-mail]'
> Subject: RE: [Sigtran] M3UA - ASP Inactive
> 
> 
> Joe,
> 
> > -----Original Message-----
> > From: Wung, Joseph [mailto:[e-mail]]
> > Sent: Tuesday, November 12, 2002 10:01 AM
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [Sigtran] M3UA - ASP Inactive
> > 
> > 
> > Brian,
> > 
> > Using the DAUD procedure to get the current SS7 network statuses
> > may be good at an ASP initialization.  But for switchover from an 
> > active ASP to an inactive ASP, requiring the newly active ASP to 
> > send DAUD to get the latest SS7 network statuses would not achieve 
> > the "seamless" requirement, considering the amount of information 
> > involved.
> [TOLGA] IMO, if one considers the relationship between 
> ASP/SGP similar to
> MTP3/MTP3 User, announcing availability of destinations after 
> ASP is ACTIVE
> might fit more to the regular SS7 case, where user parts are 
> informed about
> available destinations after MTP3 Restart. 
> > 
> > Joe
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[e-mail]]
> > Sent: Tuesday, November 12, 2002 4:41 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > 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
> > 
> > 
> > 
> > [e-mail] 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:    [e-mail]
> > > cc:    [e-mail]
> > > 
> > > 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" <[e-mail]>@ietf.org on 
> 11/11/2002
> > > 07:20:51 PM
> > > 
> > > Please respond to [e-mail]
> > > 
> > > Sent by:    [e-mail]
> > > 
> > > 
> > > To:    "Wung, Joseph" <[e-mail]>
> > > cc:    [e-mail]
> > > 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
> > > [e-mail]
> > > http://www.openss7.org/
> > > _______________________________________________
> > > Sigtran mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > -- 
> > Brian F. G. Bidulock
> > [e-mail]
> > http://www.openss7.org/
> > _______________________________________________
> > Sigtran mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > _______________________________________________
> > Sigtran mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> _______________________________________________
> Sigtran mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
_______________________________________________
Sigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sigtran