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

From: "Zannin, Francois" <[email-masked]>
Date: Tue, 26 Mar 2002 10:21:52 +0100

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

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.

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 26 Mar 2002 08:55:38 -0500

Francois,

Please see comments below.

  Tolga

> 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,
>
[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.
> available to start the traffic (already discussed in a recent
[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.
> converge to a homogeneous network, this is not an implementation
[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.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 26 Mar 2002 13:29:04 -0600

Francois,

Tolga's statements about the history of the matter is
accurate.  ASP have to coordinate state between them:
call or transaction state.  To do this they must be
able to communicate with other ASPs serving the same
AS.  NTFY is the SG notifying ASPs of its view of AS
(and in the case of ASP failure, ASP) state.  It is
considered advisory only.

When an ASP joins an AS, say in loadshare, it must have
already sychronized call and transaction state with other
ASPs serving the AS or it will be unable to assume load.
In synchronizing call and transaction state with the other
ASPs serving the AS, it was the view that the ASP knows
the definitive state of the AS.

I still think that it would be useful, however, for the
SG to notify a newly regsitered ASP of its view of the
AS (and even failed ASP) state as a sort of MTP-Restart-like
procedure for AS.  This information could be used at the
ASP in an advisory fashion.

However, what actions are taken at an ASP in response to
a NTFY message is completely up to the ASP and is not
specified.  A draft for inter-ASP communication exists.
If you are interested in standardizing ASP-ASP communication
to coordinate call and transaction state as well as overall
AS state, perhaps you would be interested in contributing
to that draft.

--brian

Tolga Asveren wrote:                                        (Tue, 26 Mar 2002 08:55:38)

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