Subject: RE: [Sigtran] M3UA - ASP Inactive

From: "Wung, Joseph" <[email-masked]>
Date: Tue, 12 Nov 2002 10:01:04 -0500

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.

Joe

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, November 12, 2002 4:41 AM
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: [email-masked]
Date: Tue, 12 Nov 2002 20:55:58 +0530

Hi,

I would agree with Jeffery that SSNM messages should be processed by ASP in
INACTIVE state also.
Since RC is an optional parameter inside the SSNM, it is not mandatory to have
the AS registered before sending the SSNM.
During MTP Restart also, the SSNM can be sent to all the ACTIVE/INACTIVE  ASPs
instead of only ACTIVE ASPs.
We had a concensus regarding this approach at the interop.

Regards
Anshoo.

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 12, 2002 3:10 PM
Subject: Re: [Sigtran] M3UA - ASP Inactive

> where the restarting behavior of SG MTP and ASP AS was addressed.  This is why
> 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.
>
> and can obtain an update any time that it likes once it is active, or can skip
> (When an AS is inactive, the SG is not even required to maintain valid routing
> The correct procedure for a restarting ASP (an ASP going ASP-ACTIVE for an AS)
> The intention here was that in non-cluster routed networks with a large number
> Restart Ends to an active ASP may be a significant amount of information (long
> during the ASP-INACTIVE state will not only lose normal SSNM messages but will
> Also, the correct procedure for an ASP is described in Section 4.6 as follows:
>
> 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
> attention, much discussion and clear consensus before the move to the RFC and
> The ASPs at the plugtest that failed to implement the simple DAUD procedure as
> can assume when they go active that all destinations are available and rely on
> unavailable or congested destination to which the AS attempts to send.  So the
> out of sync with actual conditions when signalling traffic management messages
> that the SS7 network itself implements responsive procedures that the ASP will
> There was also the problem of dynamic registration with regard to SSNM.  This
AS,
> AS even when it has not yet registered for the AS.  Considering that there is
> have an RC value assigned to an ASP which is in the ASP-INACTIVE state for an
> outweigh any misunderstood advantage and this is why the RFC says SHOULD NOT.
> > companies that their ASPs desire to receive SSNM during ASP-INACTIVE. Those
> > > being sent to the ASP.  In fact, the ASP in this state would like to know

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

---

From: "Zannin, Francois" <[email-masked]>
Date: Tue, 12 Nov 2002 17:00:09 +0100

Hi,

Given that a SSNM reflects the state of a ss7 destination in the ss7 network, all potential users of the PC, whatever is the SI, are impacted by the SSNM.

Now, if we have several AS served by an ASP, when a SSNM is received, it seems sensible to use this ss7 destination state for the update of the routing of all AS through the concerned SG.

When a new AS becomes ACTIVE on a SG and another AS of the same ASP was already ACTIVE on the same SG; it is useless to send a DAUD (or a message) for a destination that we already know as unavailable.

A "STP like" behavior of the SG regarding the AS can be a good solution for the startup phase of an ASP platform. All ss7 destination can be considered as available unless receipt of a DUNA from the SG. This DUNA can be sent after the ASP_UP phase and only the differential are sent by the SG to the ASP, whatever is the AS(s) state.

Regards, 
	Francois Z.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, November 12, 2002 4:26 PM
To: [email-masked]
Subject: Re: [Sigtran] M3UA - ASP Inactive

Hi,

Regards
Anshoo.

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 12, 2002 3:10 PM
Subject: Re: [Sigtran] M3UA - ASP Inactive

AS,

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 12 Nov 2002 11:23:11 -0500

Joe,

> From: Wung, Joseph [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2002 10:01 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] M3UA - ASP Inactive
> 
> 
> Brian,
> 
[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.

---

From: "Wung, Joseph" <[email-masked]>
Date: Tue, 12 Nov 2002 11:38:56 -0500

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:[email-masked]]
Sent: Tuesday, November 12, 2002 11:23 AM
To: [email-masked]'
Subject: RE: [Sigtran] M3UA - ASP Inactive

Joe,

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 12 Nov 2002 12:06:45 -0500

Anshoo,

> Sent: Tuesday, November 12, 2002 10:26 AM
> To: [email-masked]
[TOLGA] RC is not optional, it is semi-optional, i.e. if traffic for more
than one AS is carried over one association, it is mandatory.
> instead of only ACTIVE ASPs.
[TOLGA] All of this is quite gray area. If you think this as similar to
MTP3-Restart, in SS7 case, in this situation MTP3 informs user parts about
the available destinations.
> We had a concensus regarding this approach at the interop.
[TOLGA] Who is "we"? I think interoperability is not the correct place to
decide for binding decisions.

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 12 Nov 2002 15:52:36 -0500

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

> Sent: Tuesday, November 12, 2002 11:39 AM
> To: Tolga Asveren; [email-masked]'

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 12 Nov 2002 16:17:30 -0500

Francois,

I also agree with your comments to some extent but please see my comments
below.

   Tolga

> From: Zannin, Francois [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2002 11:00 AM
> To: [email-masked]; [email-masked]
> Given that a SSNM reflects the state of a ss7 destination in 
> the ss7 network, all potential users of the PC, whatever is 
> the SI, are impacted by the SSNM.
> 
> Now, if we have several AS served by an ASP, when a SSNM is 
> received, it seems sensible to use this ss7 destination state 
> for the update of the routing of all AS through the concerned SG.
> 
> When a new AS becomes ACTIVE on a SG and another AS of the 
> same ASP was already ACTIVE on the same SG; it is useless to 
> send a DAUD (or a message) for a destination that we already 
> know as unavailable.
[TOLGA] For that I am not so sure. I remember that there was a sample
configuration presented long time ago, where for different AS, availability
of destination might be different (I think it was a configuration where SG
is connected to a SEP with both F-link and via a STP, where messages from SG
with a specific OPC are discarded by that SEP, if they are not sent via the
F-link)
> 
> A "STP like" behavior of the SG regarding the AS can be a 
> good solution for the startup phase of an ASP platform. All 
> ss7 destination can be considered as available unless receipt 
> of a DUNA from the SG. This DUNA can be sent after the ASP_UP 
> phase and only the differential are sent by the SG to the 
> ASP, whatever is the AS(s) state.
[TOLGA] How does SG know, for which destinations a particular ASP is
interested in? And also conceptually it is not elegant to have a "STP like
behaviour" on SG, where we consider relationship between ASP/SG as a
MTP3/User Part relationship.

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 13 Nov 2002 09:51:56 -0500

Joe,

> Sent: Wednesday, November 13, 2002 9:22 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> To allow SGP to send SSNM messages to an Inactive ASP will be
> about making the Inactive ASP hot standby, meaning that it
> has the same view of the SS7 newtork as its counterpart ASP
> that is currently Active.  At any moment the need for a switchover 
> arises, the previously Inactive ASP can take over without
> disruptting services to their MTP users, which would be
> impossilbe if the newly Active ASP has to use DAUD to get
> the current view of the SS7 network as the RFC stands today.
[TOLGA] My opinion is, if one really wants uninterrupted service, one should
use loadsharing mode. Furthermore, for uninterrupted service user parts will
be also synchronized, so they will preserve destination information.
> Sent: Wednesday, November 13, 2002 1:29 AM
> To: [email-masked]
> Cc: [email-masked]
> anssharma,
> [email-masked] wrote:                        (Wed, 13 Nov 2002
> 09:32:09)
> > > [TOLGA] Who is "we"? I think interoperability is not the 
> correct place
> to
> > [Anshoo]
> > But it is the best place to see where all the 
> implementations are headed.
> And if
> >  all the implementations have a
> > good reason for going against a SHOULD in the RFC, then 
> there is a good
> reason
> > to change that should into MAY.
> 
> I seriously doubt that "all implementations" were 
> represented.  Also, the
> RFC
> is a Proposed Standard.  Before it can move to a Standard, 
> there must be
> significant implementation and interoperability.  The correct 
> place for
> changes of that nature would probably be in the "Standard" 
> rather than the
> "Proposed Standard".
> 
> It would not be wise to change this behavior unless there is a valid
> technical
> argument to begin with and then the ramifications of the change on
> interoperability and the function of the protocol are considered.
> 
> Neither have been presented.  On the other hand, technical 
> arguments and
> interoperability considerations have been made for the RFC as 
> it stands.
> This
> is why the SHOULD NOT is there in the first place.  MAY is 
> reserved for
> optional capabilitities or sligtly varying that some might 
> think has some
> market value but has no impact on imteroperability.
> 
> I don't think that one can make a case for MAY.  You are 
> welcome to try.
> 
> Here is a list of issues that I think that you will have to 
> resolve before
> a MAY could be considered:
> 
> 1)  What information is an SG then required to send to an ASP 
> when it moves
>     from an undefined or unregistered state to ASP-INACTIVE for an AS?
> 
>     If the SG is expected to send historical information on 
> acessibility,
>     restriction and congestion, then it is doing no more than it would
>     in answering a DAUD.  When is this "automatic" DAUD 
> considered sent?
> 
> 2)  Because the SG ASP state and the ASP state can be out of
> synchronization,
>     what error procedures are necessary in response to SSNM 
> sent in the
>     ASP-INACTIVE state?  That is, when the SG sends SSNM or 
> DATA to an ASP
>     that it considers in the ASP-ACTIVE state for some AS, 
> there are error
>     procedures (Unexpected Message) for handling SSNM or DATA 
> sent to an ASP
>     in the ASP-INACTIVE state.
> 
>     Currently the ASP can send ASPAC to an SG sending SSNM or 
> DATA to an
>     ASP in the ASP-INACTIVE state at the ASP to attempt to 
> resynchronize
>     state between the ASP and the SG.  If the ASP has the AS 
> unregistered
>     or in another undefined state, what can it do when it 
> receives SSNM?
>     It would likely send an "Invalid Routing Context" which 
> the SG can do
>     what with?  It cannot send unsolicited ASP Inactive Ack 
> as it could
> before
>     to resynchronized the ASP Inactive state: is it to delete 
> the ASP from
>     the AS altogether?  With no indication to the ASP?
> 
> 3)  What impact would this change have on the application at the ASP?
> 
>     It is generally agreed that the ASP-INACTIVE state for an 
> AS represents
>     the absense of the MTP User part for the AS.  (And maybe 
> this is the
> what
>     makes sending SSNM to inactive ASPs the worst idea.)  So 
> when an ASP
> that
>     is ASP-INACTIVE for an AS has no user part.  This means 
> that there is
>     no application to send MTP-PAUSE, MTP-STATUS and 
> MTP-RESUME to during
> this
>     state.  All that the ASP could do is maintain this information
> internally
>     at the ASP.  When the MTP User application reenables for 
> the AS and the
>     ASP goes ASP-ACTIVE for the AS. the ASP would have to 
> delivere this
>     information to the MTP User no differntly than the DAUD procedure
> provides
>     for today.  If the MTP User application already has the 
> information
> (from
>     another ASP or shared memory or some other place where 
> also the shared
>     circuit state and/or transaction state is held) 
> collecting it in the ASP
>     before this was a waste of time and might reveal contradictory
>     information.
> 
>     One should not forget that in the backhaul case, M3UA messages
> correspond
>     to MTP User primitives (MTP-PAUSE, MTP-RESUME, MTP-STATUS and
>     MTP-TRANSFER, and allusions to MTP-RESTART-ENDS).  While 
> the ASP is
>     ASP-INACTIVE for an AS, no primitives should cross the 
> boundary.  The
> MTP
>     User might not even be bound to the MTP-SAP, and, even if 
> it is, it
>     certainly cannot be expected to be processing MTP 
> primitives when it has
>     not acitvated for the MTP-SAP.
> 
>     I the current situation, the MTP User can rely on the 
> fact that the ASP
>     will perform DAUD (if necessary) when moving to 
> ASP-ACITVE for the AS
> and
>     will deliver the MTP-RESTART-ENDS primitive containing 
> the status of all
>     destinations.
> 
> 
> Well, I could easily go on, but can you address these three 
> issues first?
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 13 Nov 2002 09:54:49 -0500

Brian,

> From: Tolga Asveren 
> Sent: Wednesday, November 13, 2002 9:49 AM
> To: [email-masked]'
> > Sent: Wednesday, November 13, 2002 9:06 AM
> > To: Tolga Asveren
> > Cc: [email-masked]
> > Tolga Asveren wrote:                                 (Wed, 13 
> > Nov 2002 08:39:10)
> > 
> > > [TOLGA] Yes, after looking to 3.4.1 I see it is decribed 
> > like you said. IMO,
> > > it is another thing in the RFC, which nees to be chnaged. 
> > Because for
> > > different AS, availability infoirmation might be different 
> > and the construct
> > > for the communciation between ASP/SGP is AS. For those two 
> > reasons, I
> > > propose this to be changed.
> > 
> > What is it that you propsed be changed, and how?
> [TOLGA]"Where a Routing Key has not been coordinated between 
> the SGP and ASP, sending of Routing Context is not required. 
> " I don't recall the story behind this sentence, if you do, 
> what was is? Why do we want to send SSNM to ASP with no 
> registered/preconfigured AS? To provide some kind of flexibility?
[TOLGA] Brian you already answered it, thanks. So, it does not cover the
case where dynamic registration is used and no registration is done yet. 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 14 Nov 2002 09:04:21 -0500

I agree with Brian's comments, user part entity serving a specific AS is
either active or not from M3UA point of view. 

   Tolga

> Sent: Thursday, November 14, 2002 2:09 AM
> [email-masked] wrote:                                  
>                    (Thu, 14 Nov 2002 11:23:11)
> > [Anshoo]
> > It should be the same information that you propose sending 
> a newly Active ASP.
> > Even if the SG does not send any information, it should be 
> the responsibility
> > of the ASP to AUDIT the Status of the Point Codes that it would be
> > communicating with.
> 
> So you are going further to say that INACTIVE ASPs can now send DAUD?
> 
> > [Anshoo]
> > There is no need to combine both SSNM and DATA messages.
> 
> Yes there is.  These are both primitives of the MTP/MTP-User 
> interface.
> It makes no sense to exporting the MTP/MTP-User interface to send some
> primitives and not others.
> 
> > [Anshoo]
> > The User Part not existing on an INACTIVE ASP need not be 
> the case, the User
> > Part might actually not be transferring Data but still can 
> reside on an
> > INACTIVE ASP.
> 
> No, this is the definition of ASP INACTIVE for exporting the 
> MTP/MTP-User
> interface, that when the ASP is INACTIVE for an AS, it is not 
> prepared to
> receive any MTP-User primitives.  If an ASP wants to receive 
> MTP User primitives
> when it is not processing them, it should use Broadcast Mode, 
> for which this
> was intended.
> 
> > Moreover the User Part might be available on some other 
> ASP, which is ACTIVE
> > and hence the STATE of the DPCs at the User Part are out of 
> sync with the
> > underlying M3UA at the newly Active ASP after a 
> switchover... This is
> > actually a case for supporting SSNM in INACTIVE State.
> 
> It think you are missing an important point of M3UA here: 
> ASPs must coordinate
> call state, connection state and transaction state perform 
> anything near a
> smooth switchover.  The desintation state is trivial compared 
> to the amount of
> state that the MTP-User must share between ASPs.  This is the 
> responsibility
> of an ASP to ASP protocol.  If you want to synchronize (loose 
> or tight)
> multiple ASPs on the same AS, use Broadcast traffic mode.
> 
> 
> > [Anshoo]
> > If the User Part has not bound to MTP-SAP on M3UA at ASP, 
> it would not receive
> > any of the MTP3 PAUSE, RESUME etc.. Indications. But if it 
> has already bound
> > while the ASP is in INACTIVE State, it means that it is 
> ready to process MTP3
> > Indications. The M3UA at ASP can always update the Status 
> of the DPCs in
> > INACTIVE State, even when it is not indicating it to the 
> Users above.
> 
> The ASP M3UA is never expected to store MTP internal state, 
> nor to store MTP-User
> state: it is at the boundary of the MTP/MTP-User interface.  
> The ASP cannot
> correctly perform the responsive MTP-PAUSE and MTP-STATUS 
> procedures of Q.704
> in such an arrangement, and transferring copies of these 
> primitives to users
> in the INACTIVE state will actually break the 1, 2n, 3n, 
> procedures (by
> prematurely delivering MTP-PAUSE and MTP-STATUS to the 
> MTP-User).  MTP-PAUSE
> and MTP-STATUS is a more complicated state machine than just 
> storing the
> status.  MTP (at the SG) actually needs to know the number of 
> times that the
> MTP-User (that is the AS and not a particular ASP) has 
> attempted to send to
> inaccessible or congested destinations to correctly perform 
> the procedure.
> 
> > [Anshoo]
> > I find that allowing SSNM in INACTIVE State would only be useful.
> 
> I find it erroneous and incorrect.  Use Broadcast mode: it 
> will provide what
> you want to acheive without altering this behavior and 
> destroying traffic
> modes other than Active/Standby.
> 
> I still to not see a technical argument as to why you think 
> this change is
> necessary.
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/