RE: M3UA notify message

Brian,

State sharing/State coordination etc.. are all not well defined terms. What
I mean is that each SGP needs to execute ASPTM/ASPSM state machine
procedures independently and use their independent states for that
purpose -but based on what I read in this thread it seems that there is no
common interpretation about this-.

Please see below for more comments.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Thursday, February 23, 2006 1:04 AM
> To: [email protected]
> Cc: [email protected]
> Subject: Re: [Sigtran] M3UA notify message
>
>
> Prabind,
>
> You are correct, there is a case where the ASP state is shared across
> the SGPs making up an SG: in the Override traffic mode AS it is
> necessary to share which ASP is "Active" and which is "Standby" as only
> one ASP can be Active for the AS.
[TOLGA]I am not sure about this. All section 4.3 talks about SGPs and ASPs
as peers of the procedures to be followed. For example, if one looks to
4.3.4.3 ASP Active Procedures , one can see that all traffic mode procedures
are described from SGP point of view, not from SG point of view. We can talk
about benefits of different approaches but my understanding according to the
current text is that traffic mode decisions are done in each SGP
independently, but please note that a well-defined and explained behavior is
necessary to prevent interoperability issues.

Please also keep in mind the first item in Greg's e-mail you quoted before:
    1) Each ASP-SGP association uses the M3UA protocol independently

This, IMHO is an important principle and we shouldn't give it up.
>
> This is also a case where state transitions directly associated with
> ASPTM/ASPSM message procedures must be considered on an SG-wide basis,
> contrary to Tolga's previous statements on this thread.
[TOLGA]Before I reply, I need to know which procedures you specifically have
in mind.
>
> It is possible, but perhaps less important to interoperability, that an
> SG could coordinate the ASP state for ASPs in a Loadshare or Broadcast
> AS.  That is, when loadsharing, the selection algorithm at an SGP could
> consider the availability of ASPs to other SGPs to more equally
> distribute traffic.  For Broadcast mode AS, consideration of ASP state
> across the SGP could provide a more optimal broadcast of traffic (i.e.
> without sending multiple messages to or missing completely an ASP).
[TOLGA]Yes, this won't effect interoperability at all.
>
> For the case of SSNM, it is possible (but not required) for the SG to
> avoid sending duplicate SSNM messagese to any given ASP.  By considering
> the ASP state on an SG-wide basis, it is possible to ensure that only
> one SSNM message is sent to an ASP (via only one SGP).
[TOLGA]Yes not required with a "MUST", but it is common sense and is
mentioned in the RFC as well, because status of SS7 destinations is kept
gloabl in the SG, afterall it is a MTP3 entity.
>
> The override and SSNM cases were given consideration in the original
> thread that led to the wording 1.4.1.  The others were not so much.
>
> Therefore, I agree that the statement in 1.4.1 should not be ammended.
[TOLGA]I humbly disagree. That NTFY is to be sent based on changes for a
global-AS state is not clear at all, especially if one considers 4.3.2 and
4.3.4.5 -please do not expect us to refer to some e-mail sent 5 years ago
each time ;-)- BTW, I really think we first need to decide what is the exact
semantics we want to have for this.
>
> --brian
>
>
> [email protected] wrote:                (Thu, 23 Feb 2006
> 09:50:04)
> >
> > I am still concerned about this statement from Tolga:
> >
> > " In any case, it is good that there is finally consensus regarding that
> > ASPSM/ASPTM procedures and associated state machines being independent
> > on
> > each SGP."
> >
> > If multiple SGPs are serving a single AS, then shouldn't the ASP states
> > also be shared across the related SGPs?
> > Else if I am wrong then the following statement in section 1.4.1 should
> > be amended to share the AS states only.
> > " Where an SG contains more than one SGP, the MTP3 routeset, SPMC and
> >    remote AS/ASP states of each SGP SHOULD be coordinated across all the
> >    SGPs."
> >
> > Tolga, further considering the sahring of ASP states then, in the case
> > of the interoperability issue (as you depicted), the rfc says that if an
> > ASP is already inactive the ASP-UP message would still be respnded by an
> > ack.
> >
> > I think the things become simpler if we consider sharing of ASP states
> > of a particular AS across all SGPs serving that AS.
> >
> >
> > Regards,
> >
> > Prabind
> >
>
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>