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

From: "Zannin, Francois" <[email-masked]>
Date: Thu, 28 Mar 2002 15:24:18 +0100

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 28 Mar 2002 09:57:57 -0500

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

> Sent: Thursday, March 28, 2002 9:24 AM
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Zannin, Francois

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Mar 2002 14:56:57 -0600

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)

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