Subject: RE: [Sigtran] M3UA: SG and notify messages

From: "Zannin, Francois" <[email-masked]>
Date: Fri, 29 Mar 2002 10:33:33 +0100

Tolga and Brian,

This simple example could apply to a phone number translation 
where only a BEGIN/END translation is required.
The master backup model only applies in case of emergency when 
a platform crashes. 
If a transaction is lost, the "user" retries in the same way 
as in the case of congestion and message loss in the ss7 network. 
I hope that TCAP transactions are always protected by timers!

This configuration can be used in order to install several 
small replicated applications in the network without the need 
for elaborate management procedures.

       +-----+               +--------ASP'-----------+
 ss7---| SG' |===+===========| Main platform for SG' |
       +-----+   |    +------|   Backup for SG" +----|
                 |    |      +------------------| DB |
                 |    |                         +----+
            . . .| . .| . . . . . . . . . . . . . . . . .
                 |    |
                 |    |    +--------ASP"-----------+
     +-----+     +--- | ---| Main platform for SG" |
ss7--| SG" |==========+====|   Backup for SG' +----|
     +-----+               +------------------| DB |
                                              +----+

I don't think that the SG can retain the ACTIVE_ACK for an 
AS (or its ASP) because it is already "using" another AS (ASP), 
something that it's not supposed to do.
The problem with this configuration (if problem there is) is the 
inability of the  application to changeback to the main platform 
without losing any ongoing TCAP transactions.

This example is only used to justify the need to define precisely 
when the NOTIFY MUST be sent. If this message has no possible use, 
maybe we can simplify the protocol and remove it (but I'm not sure 
this would be a good idea).

Francois,

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 9:57 PM
> To: [email-masked]
> Subject: Re: [Sigtran] M3UA: SG and notify messages
> 
> 
> Francois,
> 
> I agree with Tolga.  How dos ASP" serving AS_1 know that
> it can take over the circuit or transaction state in AS_1
> from ASP'?  Unless ASP' and ASP" communicate with each other
> by some other means, they will not be able to coordinate
> call/transaction state.  ASP' and ASP" must know the true
> state of the AS, the SG only sends NTFY on its impression
> of the AS state.  Activating and deactivating on the basis
> of SG NTFY could wreak havoc with call/transaction state at
> the AS, and introduce race or thrashing conditions between
> ASPs.
> 
> So, when ASP' goes active, it either knows (from ASP") that
> ASP" is already active or it goes active as master.  When ASP"
> goest active, it either knows (from ASP') that ASP' is already
> active.
> 
> Some of you comments are applicable in the "partitioned" case
> where ASPs become partitioned form each other but not the
> SG.  However, all of those are failure scenarios, (not restart
> scenarios), and are adequately addressed by NTFY("ASP Failure").
> 
> --brian
> 
> Tolga Asveren wrote:                                        
> (Thu, 28 Mar 2002 09:57:57)
> > Francois,
> > 
> > I understand your concern but,
> > 
> > 1) From SG point of view:
> > As pointed out by Brian, SG is free to send NTFY to the 
> second ASP in your
> > scenario.
> > 
> > 2) From ASP point of view:
> > I don't think, it will harm that your second ASP sends 
> ASPAC, even if the
> > first ASP is ACTIVE. Just it won't get ASPAC-ACK. So, in 
> fact you don't need
> > the NTFY.
> > 
> > 3) From system point of view:
> > This configuration is really not very realistic. Maybe just 
> for a TCAP
> > application, which does not initiate a dialogue, but just 
> answers for simple
> > Query/Response scenarios and where the application does not 
> care for the
> > broken dialogues in case of failure.
> > 
> > I don't think sending NTFY in the cases you described is a 
> bad idea. But
> > there are other ways to survive.
> > 
> >    Tolga
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Zannin, Francois [mailto:[email-masked]]
> > > Sent: Thursday, March 28, 2002 9:24 AM
> > > To: Tolga Asveren; [email-masked]
> > > Subject: RE: [Sigtran] M3UA: SG and notify messages
> > >
> > >
> > > Tolga,
> > >
> > > The case I'm thinking about is a simple configuration 
> where a service is
> > > distributed among two platform that provide the same 
> service from two
> > > different location in the IP network and with no dialog 
> between then.
> > >
> > >
> > >                        Main Appli Server (group)
> > >                        +------+  +------+  RC=1
> > >                     +--| ASP' |==| AS_1 |  PC=10
> > >     +------------+  |  +------+  +------+  SI=x
> > >     |     |      |--+
> > > ss7-| SG  | SGP1 |
> > >     |     |      |--+  Backup Appli Server (group)
> > >     +------------+  |  +------+  +------+  RC=1
> > >                     +--| ASP" |==| AS_1 |  PC=10
> > >                        +------+  +------+  SI=x
> > >
> > >     SGP1 > (PC=10,SI=x)==> RC=1
> > >        RC=1 > (ASP'=Mstr, ASP"=Bck)
> > >
> > > When the first platform is started, the SG "NOTIFY" it of the
> > > unavailability
> > > of the service so that the ASP(s) management will decide 
> automatically to
> > > send the ACTIVE (for the entire PLATFORM asp).
> > >
> > > When the second platform is started as backup, it sends 
> the ASP_UP and
> > > because it is notified that the service is already 
> available, the local
> > > management do not send the ACTIVE. As soon as the service 
> is unavailable
> > > in the SG, the backup platform is notified and then it can send
> > > the ACTIVE
> > > for the service continuity.
> > >
> > > Now, maybe this kind of configuration is unrealistic on a real
> > > network and
> > > the master/backup must be assumed with a closer harmony 
> between the
> > > master/backup platforms.
> > >
> > > This simple example is just here to justify that ASP may need to
> > > be inform
> > > of the status of an AS even if the current "available AS 
> group" is not
> > > hosted by the backup ASP platform.
> > >
> > > Again this example just to justify why I'd like to see 
> notify "hardy"
> > > recommended when an ASP becomes UP (or after a REGISTER). 
> Because it is
> > > just an information, people can decide to ignore it, but 
> people who need
> > > it won't have to request for a "specific" version of SG.
> > >
> > > Francois,
> > >
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Tuesday, March 26, 2002 8:12 PM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] M3UA: SG and notify messages
> > >
> > >
> > > Francois,
> > >
> > > For ASP-SGP case (based on your correction) which 
> specific problem do you
> > > see for NTFY?
> > >
> > >    Tolga
> > >
> > > > -----Original Message-----
> > > > From: Zannin, Francois [mailto:[email-masked]]
> > > > Sent: Tuesday, March 26, 2002 11:27 AM
> > > > To: Tolga Asveren; [email-masked]
> > > > Subject: RE: [Sigtran] M3UA: SG and notify messages
> > > >
> > > >
> > > > Tolga,
> > > >
> > > > Thank's for your point of view,
> > > > Just one mistake in my comment, see inline.
> > > >
> > > > Francois,
> > > >
> > > > -----Original Message-----
> > > > From: Tolga Asveren [mailto:[email-masked]]
> > > > Sent: Tuesday, March 26, 2002 2:56 PM
> > > > To: [email-masked]
> > > > Subject: RE: [Sigtran] M3UA: SG and notify messages
> > > >
> > > >
> > > > Francois,
> > > >
> > > > Please see comments below.
> > > >
> > > >   Tolga
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > > > Zannin, Francois
> > > > > Sent: Tuesday, March 26, 2002 4:22 AM
> > > > > To: [email-masked]
> > > > > Subject: RE: [Sigtran] M3UA: SG and notify messages
> > > > >
> > > > >
> > > > > Hi All,
> > > > >
> > > > > When the M3UA draft says that notify are sent for AS change
> > > > > of state, in an ASP point of view, I think that the initial
> > > > > state of the AS must be known before to receive the Notify
> > > > > change of state.
> > > > >
> > > > > If I develop an ASP, I think that when the ASP process is
> > > > > started, I must be sure that I will receive notify about the
> > > > > SG view of the AS state that I host, especially if my 
> management
> > > > > rely on these notifications.
> > > > [TOLGA] The crucial point is that your management shouldn't
> > > rely on NTFYs,
> > > > unless some changes are done in the draft. It was 
> proposed to trigger
> > > > starting/stopping traffic on ASP side based on NTFYs, but there
> > > wasn't too
> > > > much support for this idea.
> > > > > This indication is also useful in case of "loadshare" 
> mode when
> > > > > the Asp needs to have an indication that there is enough ASP
> > > > > available to start the traffic (already discussed in a recent
> > > > > thread).
> > > > [TOLGA] In that case, it is responsibility ASP -in an 
> implementation
> > > > dependent way- to get enough information from other 
> ASPs, to decide the
> > > > number of active ASPs for a particular AS.
> > > > >
> > > > > Because this indication is exchange between different process
> > > > > (AS / ASP) that can comes from different providers, 
> all messages
> > > > > exchanges must be specified in the recommendation if 
> we want to
> > > > > converge to a homogeneous network, this is not an 
> implementation
> > > > > issue.
> > > > [TOLGA] In my opinion, till now one of the assumptions was
> > > -although it is
> > > > not said openly- ASPs, serving the same AS will be most
> > > probably from the
> > > > same provider, because a lot of things are handled by inter-ASP
> > > > communication. This is like SGPs of the same SG are 
> going to be from the
> > > > same provider.
> > > >
> > > > [FRANCOIS]
> > > > An error in my comment, when I said different process, I thought
> > > > SGP to ASP that can comes from different providers, and this
> > > > configuration is more plausible.
> > > > If we don't specify how this information can be reliably used,
> > > > it is not usable (and maybe useless).
> > > > But if it is too late to include these precisions in 
> the RFC about the
> > > > use of the "NOTIFY", that's useless to continue on this thread.
> > > >
> > > > >
> > > > > Another point about the dynamic registration:
> > > > > When the ASP sends the register, after the "ASP UP", 
> the SG must
> > > > > consider it in the same state as an ASP that sends 
> the "ASP UP"
> > > > > in a static configuration, and then send notify to the new
> > > > > "known ASP" for the AS declared by the notify.
> > > > >
> > > > > Francois Z.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > Sent: Monday, March 25, 2002 6:51 PM
> > > > > To: Zannin, Francois
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [Sigtran] M3UA: SG and notify messages
> > > > >
> > > > >
> > > > > Zannin,,
> > > > >
> > > > > Zannin, Francois wrote:                               
>     (Mon,
> > > > > 25 Mar 2002 18:06:47)
> > > > > > Hi all,
> > > > > >
> > > > > > I have a query about the behavior of the SGP regarding
> > > > > > notify messages sent to the Asp.
> > > > > >
> > > > > > It is said that notify are sent to the Asp when the AS
> > > > > > state change. When an ASP is dynamically registered to
> > > > > > the SG, what must the SG do about this notify, do it
> > > > > > send it after the registration request/ack to inform
> > > > > > the ASP of the change of state of the ASP (from ASP-DOWN
> > > > > > to ASP-INACTIVE).
> > > > >
> > > > > Notifies are sent for AS state changes, not ASP state changes
> > > > > (except failure).
> > > > >
> > > > > >
> > > > > > Now, in a static configuration, if we have two ASP that
> > > > > > serve an AS, when the first ASP send the "ASP UP" to the
> > > > > > SG, the SG answer with an "ASP UP ack" message and then
> > > > > > send the notify ASP inactive because the AS change from
> > > > > > DOWN to INACTIVE. Then the ACTIVE/ACK messages are exchanged
> > > > > > and notify "ASP active" is sent by the SG to the ASP.
> > > > > >
> > > > > > Then, when the second ASP sends the "ASP UP" message, the
> > > > > > SG reply with an "ASP UP ack".
> > > > > > Event if the AS don't change of state (still the active)
> > > > > > do the SG send a NOTIFY "ASP active" to the "new" ASP to
> > > > > > inform it of the current state of the AS, state known by
> > > > > > the SG but unknown by the "new" ASP.
> > > > >
> > > > > It is not required, but I do: NTFY messages are advisory
> > > > > and it certainly makes sense to notify a newly registering
> > > > > ASP of the state of the AS.
> > > > >
> > > > >
> > > > > > When we said that a notify is sent when an AS change of
> > > > > > state, does it mean change of state also in an ASP point
> > > > > > of view?
> > > > >
> > > > > No, that's not what M3UA says: it only requires NTFY for
> > > > > AS state changes from the SG viewpoint.  However, it also
> > > > > does not preclude NTFY from being sent at any time.  I prefer
> > > > > the approach where newly joining ASPs are given the current
> > > > > state of the AS regardless of whether an AS state change
> > > > > occurs.  M3UA permits this but does not require it.
> > > > >
> > > > > I think that any ASP designed to rely on these notifications
> > > > > after joining, would prefer to require the SG to give such
> > > > > notifications in the case of dynamic regsitration.  Perhaps
> > > > > we should capture this in the kmplementor's guide.
> > > > >
> > > > > --brian
> > > > >
> > > > >
> > > > > >
> > > > > > Francois Zannin.
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > >
> > >
> > > _______________________________________________
> > > 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: "Tolga Asveren" <[email-masked]>
Date: Fri, 29 Mar 2002 08:46:01 -0500

Francois,

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Zannin, Francois
> Sent: Friday, March 29, 2002 4:34 AM
> To: [email-masked]; [email-masked]
[TOLGA] That is exactly what I described in my message as 3).
>                  |    |      +------------------| DB |
[TOLGA] I disagree with you. For 1+1 case, I expect SGP to behave like this.
Not to send ASPAC-ACK to the second ASP. Why do you think, this is a
violation of the protocol? And also, if you really don't care about your
lost transactions, then even Override mode should work. The second ASP
becomes Master and the other one Standby. I don't see any problem.
> this would be a good idea).
[TOLGA] When NTFY MUST be sent is precisely defined.
m3uav12 4.3.4.5:
"A Notify message reflecting a change in the AS state MUST be sent to all
ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status
Information and any ASP Identifier of the failed ASP."

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 29 Mar 2002 13:08:31 -0600

Francois,

Mated pair SCPs were designed to handle this situation.
Each SCP has a different point code and failover is
handled by STPs either at or behind the SG.  In this
case each ASP is a different AS.

--brian

Zannin, Francois wrote:                                   (Fri, 29 Mar 2002 10:33:33)

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